Make scheduled builds full official builds (#703)

Publish all the artifacts to the blob feeds for the scheduled builds so
the vendors don't have to do thier error prone builds.

Some minor cleanup to remove some pipeline warnings.

Change ClrStack casing in help docs to be consistent

Remove SDK entry in global.json so VS works

Update version prefix to 5.0.0
This commit is contained in:
Mike McLaughlin 2019-12-16 22:41:59 -08:00 коммит произвёл GitHub
Родитель 4d2a8a4c6c
Коммит 676d9c6a90
Не найден ключ, соответствующий данной подписи
Идентификатор ключа GPG: 4AEE18F83AFDEB23
6 изменённых файлов: 38 добавлений и 46 удалений

Просмотреть файл

@ -25,6 +25,7 @@ jobs:
_BuildArch: x86
_PublishArtifacts: bin/Windows_NT.x86.Release
Build_Release_arm:
_BuildOnly: true
_BuildConfig: Release
_BuildArch: arm
_PublishArtifacts: bin/Windows_NT.arm.Release
@ -54,6 +55,7 @@ jobs:
strategy:
matrix:
Build_Release:
_BuildOnly: true
_BuildConfig: Release
_BuildArch: arm
_PublishArtifacts: bin/Linux.arm.Release
@ -67,6 +69,7 @@ jobs:
strategy:
matrix:
Build_Release:
_BuildOnly: true
_BuildConfig: Release
_BuildArch: arm64
_PublishArtifacts: bin/Linux.arm64.Release
@ -212,7 +215,7 @@ jobs:
- MacOS
- Linux_cross
- Linux_cross64
condition: and(succeeded(), ne(variables['Build.Reason'], 'Schedule'))
condition: succeeded()
pool:
name: NetCoreInternal-Pool
queue: BuildPool.Windows.10.Amd64.VS2017
@ -318,12 +321,14 @@ jobs:
inputs:
filePath: eng\common\sdk-task.ps1
arguments: -task PublishToSymbolServers -restore -msbuildEngine dotnet -configuration Release -verbosity normal
/p:UsingToolSymbolUploader=true
/p:DotNetSymbolServerTokenMsdl=$(microsoft-symbol-server-pat)
/p:DotNetSymbolServerTokenSymWeb=$(symweb-symbol-server-pat)
/p:PDBArtifactsDirectory='$(Build.SourcesDirectory)/artifacts/SymStore/**'
/p:BlobBasePath='$(Build.SourcesDirectory)/artifacts/packages/Release/**'
continueOnError: true
condition: and(succeeded(), eq(variables['PublishSymbols'], 'true'))
# Publish package and log build artifacts
- task: PublishBuildArtifacts@1

Просмотреть файл

@ -3,7 +3,7 @@
<PropertyGroup>
<RepositoryUrl>https://github.com/dotnet/diagnostics</RepositoryUrl>
<PreReleaseVersionLabel>preview</PreReleaseVersionLabel>
<VersionPrefix>3.0.0</VersionPrefix>
<VersionPrefix>5.0.0</VersionPrefix>
<DotNetUseShippingVersions>true</DotNetUseShippingVersions>
<AutoGenerateAssemblyVersion>true</AutoGenerateAssemblyVersion>
</PropertyGroup>
@ -22,7 +22,6 @@
<!-- Opt-in/out repo features -->
<UsingToolXliff>false</UsingToolXliff>
<UsingToolNetFrameworkReferenceAssemblies>true</UsingToolNetFrameworkReferenceAssemblies>
<UsingToolSymbolUploader>true</UsingToolSymbolUploader>
<!-- Build tools -->
<MicrosoftNetCompilersVersion>3.0.0</MicrosoftNetCompilersVersion>
<!-- CoreFX -->

Просмотреть файл

@ -84,7 +84,6 @@ jobs:
- _PhaseName : ${{ parameters.name }}
- _HelixType: build/product
- _HelixBuildConfig: $(_BuildConfig)
- _Pipeline_StreamDumpDir: $(Build.SourcesDirectory)/artifacts/tmp/$(_BuildConfig)/streams
# Only enable publishing in non-public, non PR scenarios.
- ${{ if and(ne(variables['System.TeamProject'], 'public'), notin(variables['Build.Reason'], 'PullRequest')) }}:
@ -97,14 +96,6 @@ jobs:
- ${{ if ne(parameters.testOnly, 'true') }}:
- _LinuxScript: $(Build.SourcesDirectory)/eng/cibuild.sh
- ${{ if eq(variables['Build.Reason'], 'Schedule') }}:
- ${{ if eq(parameters.osGroup, 'Windows_NT') }}:
- _DailyTest: -dailytest
- ${{ if ne(parameters.osGroup, 'Windows_NT') }}:
- _DailyTest: --dailytest
- ${{ if ne(variables['Build.Reason'], 'Schedule') }}:
- _DailyTest: ''
# This is only required for cross builds.
- ${{ if eq(parameters.crossrootfsDir, '') }}:
- _RootFs: ''
@ -113,7 +104,7 @@ jobs:
steps:
- ${{ if eq(parameters.osGroup, 'Windows_NT') }}:
- script: $(Build.SourcesDirectory)\eng\cibuild.cmd $(_DailyTest)
- script: $(Build.SourcesDirectory)\eng\cibuild.cmd
-configuration $(_BuildConfig)
-architecture $(_BuildArch)
-prepareMachine
@ -134,7 +125,7 @@ jobs:
--docker-image $(_DockerImageName)
--source-directory $(Build.SourcesDirectory)
--container-name diagnostics-$(Build.BuildId)
$(_LinuxScript) $(_DailyTest) $(_RootFs)
$(_LinuxScript) $(_RootFs)
--configuration $(_BuildConfig)
--architecture $(_BuildArch)
--prepareMachine
@ -144,7 +135,7 @@ jobs:
condition: succeeded()
- ${{ if eq(parameters.osGroup, 'MacOS') }}:
- script: $(Build.SourcesDirectory)/eng/cibuild.sh $(_DailyTest)
- script: $(Build.SourcesDirectory)/eng/cibuild.sh
--configuration $(_BuildConfig)
--architecture $(_BuildArch)
--prepareMachine
@ -180,7 +171,7 @@ jobs:
- task: PublishBuildArtifacts@1
displayName: Publish Stream Artifacts on failure
inputs:
PathtoPublish: $(_Pipeline_StreamDumpDir)
PathtoPublish: '$(Build.SourcesDirectory)/artifacts/tmp/$(_BuildConfig)/streams'
PublishLocation: Container
ArtifactName: Streams_$(_PhaseName)_$(_BuildArch)_$(_BuildConfig)
continueOnError: true
@ -216,4 +207,4 @@ jobs:
mergeTestResults: true
buildConfiguration: ${{ parameters.name }}
continueOnError: true
condition: always()
condition: ne(variables['_BuildOnly'], 'true')

Просмотреть файл

@ -1,7 +1,4 @@
{
"sdk": {
"version": "3.0.101"
},
"tools": {
"dotnet": "3.0.101"
},

Просмотреть файл

@ -29,7 +29,7 @@ DumpAsync IP2MD
DumpDelegate U
DumpStackObjects (dso) DumpStack
DumpHeap EEStack
DumpVC CLRStack
DumpVC ClrStack
GCRoot GCInfo
ObjSize EHInfo
FinalizeQueue BPMD (bpmd)
@ -116,7 +116,7 @@ dump creation time to bring those structures into the minidump, and allow a
minimum set of SOS debugging commands to work. At this time, those commands
that can provide full or partial output are:
CLRStack
ClrStack
Threads
Help
PrintException
@ -345,7 +345,7 @@ COMMAND: dumpstackobjects.
This command will display any managed objects it finds within the bounds of
the current stack. Combined with the stack tracing commands like K and
!CLRStack, it is a good aid to determining the values of locals and
!ClrStack, it is a good aid to determining the values of locals and
parameters.
If you use the -verify option, each non-static CLASS field of an object
@ -567,7 +567,7 @@ places:
First, all stacks will be searched for roots, then handle tables, and finally
the reachable queue of the finalizer. Some caution about the stack roots:
!GCRoot doesn't attempt to determine if a stack root it encountered is valid
or is old (discarded) data. You would have to use !CLRStack and !U to
or is old (discarded) data. You would have to use !ClrStack and !U to
disassemble the frame that the local or argument value belongs to in order to
determine if it is still in use.
@ -854,10 +854,10 @@ exceptions by switching to the thread in question, and running
\\
COMMAND: clrstack.
!CLRStack [-a] [-l] [-p] [-n] [-f] [-r] [-all]
!CLRStack [-a] [-l] [-p] [-i] [variable name] [frame]
!ClrStack [-a] [-l] [-p] [-n] [-f] [-r] [-all]
!ClrStack [-a] [-l] [-p] [-i] [variable name] [frame]
CLRStack attempts to provide a true stack trace for managed code only. It is
ClrStack attempts to provide a true stack trace for managed code only. It is
handy for clean, simple traces when debugging straightforward managed
programs. The -p parameter will show arguments to the managed function. The
-l parameter can be used to show information on local variables in a frame.
@ -893,27 +893,27 @@ in myapp.ini and re-run:
GenerateTrackingInfo=1
AllowOptimize=0
The -i option is a new EXPERIMENTAL addition to CLRStack and will use the ICorDebug
The -i option is a new EXPERIMENTAL addition to ClrStack and will use the ICorDebug
interfaces to display the managed stack and variables. With this option you can also
view and expand arrays and fields for managed variables. If a stack frame number is
specified in the command line, CLRStack will show you the parameters and/or locals
specified in the command line, ClrStack will show you the parameters and/or locals
only for that frame (provided you specify -l or -p or -a of course). If a variable
name and a stack frame number are specified in the command line, CLRStack will show
name and a stack frame number are specified in the command line, ClrStack will show
you the parameters and/or locals for that frame, and will also show you the fields
for that variable name you specified. Here are some examples:
!CLRStack -i -a : This will show you all parameters and locals for all frames
!CLRStack -i -a 3 : This will show you all parameters and locals, for frame 3
!CLRStack -i var1 0 : This will show you the fields of 'var1' for frame 0
!CLRStack -i var1.abc 2 : This will show you the fields of 'var1', and expand
!ClrStack -i -a : This will show you all parameters and locals for all frames
!ClrStack -i -a 3 : This will show you all parameters and locals, for frame 3
!ClrStack -i var1 0 : This will show you the fields of 'var1' for frame 0
!ClrStack -i var1.abc 2 : This will show you the fields of 'var1', and expand
'var1.abc' to show you the fields of the 'abc' field,
for frame 2.
!CLRStack -i var1.[basetype] 0 : This will show you the fields of 'var1', and
!ClrStack -i var1.[basetype] 0 : This will show you the fields of 'var1', and
expand the base type of 'var1' to show you its
fields.
!CLRStack -i var1.[6] 0 : If 'var1' is an array, this will show you the element
!ClrStack -i var1.[6] 0 : If 'var1' is an array, this will show you the element
at index 6 in the array, along with its fields
The -i options uses DML output for a better debugging experience, so typically you
should only need to execute "!CLRStack -i", and from there, click on the DML
should only need to execute "!ClrStack -i", and from there, click on the DML
hyperlinks to inspect the different managed stack frames and managed variables.
\\

Просмотреть файл

@ -29,7 +29,7 @@ DumpAsync (dumpasync) IP2MD (ip2md)
DumpDelegate (dumpdelegate) u (clru)
DumpStackObjects (dso) DumpStack (dumpstack)
DumpHeap (dumpheap) EEStack (eestack)
DumpVC CLRStack (clrstack)
DumpVC ClrStack (clrstack)
FinalizeQueue (finalizequeue) GCInfo
GCRoot (gcroot) EHInfo
PrintException (pe) bpmd (bpmd)
@ -226,7 +226,7 @@ DumpStackObjects [-verify] [top stack [bottom stack]]
This command will display any managed objects it finds within the bounds of
the current stack. Combined with the stack tracing commands like K and
CLRStack, it is a good aid to determining the values of locals and
ClrStack, it is a good aid to determining the values of locals and
parameters.
If you use the -verify option, each non-static CLASS field of an object
@ -469,7 +469,7 @@ places:
First, all stacks will be searched for roots, then handle tables, and finally
the reachable queue of the finalizer. Some caution about the stack roots:
GCRoot doesn't attempt to determine if a stack root it encountered is valid
or is old (discarded) data. You would have to use CLRStack and U to
or is old (discarded) data. You would have to use ClrStack and U to
disassemble the frame that the local or argument value belongs to in order to
determine if it is still in use.
@ -617,10 +617,10 @@ exceptions by switching to the thread in question, and running
\\
COMMAND: clrstack.
CLRStack [-a] [-l] [-p] [-n] [-f] [-r] [-all]
CLRStack [-a] [-l] [-p] [-i] [variable name] [frame]
ClrStack [-a] [-l] [-p] [-n] [-f] [-r] [-all]
ClrStack [-a] [-l] [-p] [-i] [variable name] [frame]
CLRStack attempts to provide a true stack trace for managed code only. It is
ClrStack attempts to provide a true stack trace for managed code only. It is
handy for clean, simple traces when debugging straightforward managed
programs. The -p parameter will show arguments to the managed function. The
-l parameter can be used to show information on local variables in a frame.
@ -656,12 +656,12 @@ in myapp.ini and re-run:
GenerateTrackingInfo=1
AllowOptimize=0
The -i option is a new EXPERIMENTAL addition to CLRStack and will use the ICorDebug
The -i option is a new EXPERIMENTAL addition to ClrStack and will use the ICorDebug
interfaces to display the managed stack and variables. With this option you can also
view and expand arrays and fields for managed variables. If a stack frame number is
specified in the command line, CLRStack will show you the parameters and/or locals
specified in the command line, ClrStack will show you the parameters and/or locals
only for that frame (provided you specify -l or -p or -a of course). If a variable
name and a stack frame number are specified in the command line, CLRStack will show
name and a stack frame number are specified in the command line, ClrStack will show
you the parameters and/or locals for that frame, and will also show you the fields
for that variable name you specified. Here are some examples:
clrstack -i -a : This will show you all parameters and locals for all frames