mirrors/dotnet-installer
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
dotnet-installer/eng/pipelines/templates/steps/vmr-prepare.yml

50 lines
1.7 KiB
YAML
Raw Normal View History

Add a VMR synchronization PR validation (#14918) Adds a new pipeline that will run during installer's PRs that verifies that the current VMR tooling can synchronize that particular change into the VMR.
2022-11-08 16:47:32 +00:00
### These steps clone the VMR (https://github.com/dotnet/dotnet) into $(Agent.BuildDirectory)/vmr
### Component Governance scan is also triggered over the VMR's non-repo sources
parameters:
- name: vmrBranch
displayName: dotnet/dotnet branch to use
type: string
default: $(Build.SourceBranchName)
Use VMR instead of the tarball for Source-Build builds (#15042) For PRs, the Source-Build leg that was running inside of the Build stage is now moved to a separate stage but runs more or less the same: https://dev.azure.com/dnceng-public/public/_build/results?buildId=97509&view=results Instead of creating the tarball, we are building the `dotnet/dotnet` repo there. For internal rolling builds, we are taking [this pipeline](https://dev.azure.com/dnceng/internal/_build/results?buildId=2056327&view=results) and merging it into `dotnet-installer-official-ci`. So it's one extra stage that runs pretty quick (faster than the Build stage by far). It won't be creating and pushing the tarball artifact anymore though. Once the rolling build is finished, there won't be no more source-build-build pipeline but instead dotnet-dotnet-official-ci which will build the dotnet/dotnet repo again instead of the tarball that was originally produced from the rolling build. The MSFT SDK from the installer build will still be consumed by it though. More details https://github.com/dotnet/arcade/issues/10677
2022-12-01 09:51:39 +00:00
- name: installerBuildResourceId
displayName: Installer build to get the commit hash to check out from
type: string
default: current
- name: skipComponentGovernanceDetection
type: boolean
default: false
Add a VMR synchronization PR validation (#14918) Adds a new pipeline that will run during installer's PRs that verifies that the current VMR tooling can synchronize that particular change into the VMR.
2022-11-08 16:47:32 +00:00
steps:
- checkout: vmr
displayName: Clone dotnet/dotnet
path: vmr
Use VMR instead of the tarball for Source-Build builds (#15042) For PRs, the Source-Build leg that was running inside of the Build stage is now moved to a separate stage but runs more or less the same: https://dev.azure.com/dnceng-public/public/_build/results?buildId=97509&view=results Instead of creating the tarball, we are building the `dotnet/dotnet` repo there. For internal rolling builds, we are taking [this pipeline](https://dev.azure.com/dnceng/internal/_build/results?buildId=2056327&view=results) and merging it into `dotnet-installer-official-ci`. So it's one extra stage that runs pretty quick (faster than the Build stage by far). It won't be creating and pushing the tarball artifact anymore though. Once the rolling build is finished, there won't be no more source-build-build pipeline but instead dotnet-dotnet-official-ci which will build the dotnet/dotnet repo again instead of the tarball that was originally produced from the rolling build. The MSFT SDK from the installer build will still be consumed by it though. More details https://github.com/dotnet/arcade/issues/10677
2022-12-01 09:51:39 +00:00
clean: true
fetchDepth: 0 # We need this so that we can check out the new commit
- ${{ if ne(parameters.installerBuildResourceId, 'current') }}:
- download: ${{ parameters.installerBuildResourceId }}
artifact: VmrRevision
displayName: Download VmrRevision
Add a VMR synchronization PR validation (#14918) Adds a new pipeline that will run during installer's PRs that verifies that the current VMR tooling can synchronize that particular change into the VMR.
2022-11-08 16:47:32 +00:00
Use VMR instead of the tarball for Source-Build builds (#15042) For PRs, the Source-Build leg that was running inside of the Build stage is now moved to a separate stage but runs more or less the same: https://dev.azure.com/dnceng-public/public/_build/results?buildId=97509&view=results Instead of creating the tarball, we are building the `dotnet/dotnet` repo there. For internal rolling builds, we are taking [this pipeline](https://dev.azure.com/dnceng/internal/_build/results?buildId=2056327&view=results) and merging it into `dotnet-installer-official-ci`. So it's one extra stage that runs pretty quick (faster than the Build stage by far). It won't be creating and pushing the tarball artifact anymore though. Once the rolling build is finished, there won't be no more source-build-build pipeline but instead dotnet-dotnet-official-ci which will build the dotnet/dotnet repo again instead of the tarball that was originally produced from the rolling build. The MSFT SDK from the installer build will still be consumed by it though. More details https://github.com/dotnet/arcade/issues/10677
2022-12-01 09:51:39 +00:00
- script: |
set -ex
sha=`head -n 1 $(Pipeline.Workspace)/${{ parameters.installerBuildResourceId }}/VmrRevision/VmrRevision.txt`
git checkout $sha
displayName: Check out dotnet/dotnet commit
workingDirectory: $(Agent.BuildDirectory)/vmr
- ${{ else }}:
- script: |
git switch -c ${{ parameters.vmrBranch }}
displayName: Checkout ${{ parameters.vmrBranch }}
workingDirectory: $(Agent.BuildDirectory)/vmr
Add a VMR synchronization PR validation (#14918) Adds a new pipeline that will run during installer's PRs that verifies that the current VMR tooling can synchronize that particular change into the VMR.
2022-11-08 16:47:32 +00:00
# TODO (https://github.com/dotnet/arcade/issues/11332): Allow full CG?
# Currently, we ignore dirs of individual repos - they have been scanned before
Use VMR instead of the tarball for Source-Build builds (#15042) For PRs, the Source-Build leg that was running inside of the Build stage is now moved to a separate stage but runs more or less the same: https://dev.azure.com/dnceng-public/public/_build/results?buildId=97509&view=results Instead of creating the tarball, we are building the `dotnet/dotnet` repo there. For internal rolling builds, we are taking [this pipeline](https://dev.azure.com/dnceng/internal/_build/results?buildId=2056327&view=results) and merging it into `dotnet-installer-official-ci`. So it's one extra stage that runs pretty quick (faster than the Build stage by far). It won't be creating and pushing the tarball artifact anymore though. Once the rolling build is finished, there won't be no more source-build-build pipeline but instead dotnet-dotnet-official-ci which will build the dotnet/dotnet repo again instead of the tarball that was originally produced from the rolling build. The MSFT SDK from the installer build will still be consumed by it though. More details https://github.com/dotnet/arcade/issues/10677
2022-12-01 09:51:39 +00:00
- ${{ if and(not(parameters.skipComponentGovernanceDetection), ne(variables['Build.Reason'], 'PullRequest'), eq(variables['System.TeamProject'], 'internal')) }}:
Add a VMR synchronization PR validation (#14918) Adds a new pipeline that will run during installer's PRs that verifies that the current VMR tooling can synchronize that particular change into the VMR.
2022-11-08 16:47:32 +00:00
- task: ComponentGovernanceComponentDetection@0
inputs:
sourceScanPath: $(Agent.BuildDirectory)/vmr
ignoreDirectories: $(Agent.BuildDirectory)/vmr/src
Reference in a new issue Copy permalink