Azure Devops 中拉取请求的构建策略是否可以使用在所述 PR 中更新的 yaml 文件？

Question

We have all our pipelines checked into code, but if we deliver a PR with changes in those pipelines, the PR Build Policies will run with the YAML-files in MASTER, not the ones that we want to check into master. It's basically a deadlock.

Say you want to remove a validation that makes all your PRs fail, so you make a PR but you can't merge it cause the build policies fail :P

PS: I know I can remove the policies, complete the merge, and add the policies back in as a manual job, but that is not really a good solution.

Answer 1

Create a separate yaml pipeline with the pre merge build steps that you then set in the PR policies for. It will always run the code from the current branch that the PR is created from.

We do it like this: (All in same repo)

1. build_steps.yml - Yaml template with build steps
2. azure-pipelines-yml - Main pipeline that has a reference to build_steps.yml to build the project
3. pre_merge.yml - Secondary pipeline that is run only by PR request which has a reference to build_steps.yml so there are no differences in the build and two places to update if something changes.

Whole yaml definition:

#pre_merge.yml
trigger: none #Pipeline should never trigger on any branches. Only invoked by the policy.

variables:
  - name: system.buildConfiguration 
    value: 'Release'

  - name: system.buildPlatform
    value: 'win10-x86'

  - name: system.debug
    value: 'false'

pool:
  vmImage: 'windows-latest'

name: $(SourceBranchName)_$(date:yyyyMMdd)$(rev:.r)

steps:
- template: build_steps.yml

And then in the policies you setup it like this:

All this applies also to classic pipelines. You need to create a seperate pre-merge build pipeline that could reference a TaskGroup with the steps used in the main build pipeline. In both cases you dont have to use a template or Taskgroup and and create the steps manually. But if the build would change in the future you have 2 places to update.

Answer 2

Just throwing this out there as an alternative. However; if desired can maintain one yaml pipeline that can do both the pre merge and the deployment.

Would want to create a variable to detect if the pipeline is running against the "master/main" branch similar to:

  IsMainBranch: $[eq(variables['Build.SourceBranch'], 'refs/heads/master')]

From there the variable will need to be a condition on subsequent jobs/stages. Personally I do not like this approach as it limits the portability of the pipelines. In addition it interjects another variable to account for; however, felt it fair to provide an alternative option.