Context
In my Azure DevOps project, I have multiple project repos using a common Azure DevOps pipeline. I have accomplished this by defining the pipeline in a core pipeline repo and then referring to it from each project repo.
Repo: core-pipeline
File: pipeline.yml
jobs:
- job: exampleJob
displayName: Example job
steps:
- checkout: core_pipeline # Not magic; see azure-pipelines.yml below.
path: $(PIPELINE_DIR_RELATIVE)
- checkout: self
path: $(PROJECT_DIR_RELATIVE)
- task: ShellScript@2
displayName: Show project repo info
inputs:
scriptPath: $(PIPELINE_DIR)/showProjectInfo.sh
cwd: $(PROJECT_DIR)
variables:
__SOURCES_DIR__: s
PIPELINE_DIR_RELATIVE: $(__SOURCES_DIR__)/core-pipeline
PIPELINE_DIR: $(Pipeline.Workspace)/$(PIPELINE_DIR_RELATIVE)
PROJECT_DIR_RELATIVE: $(__SOURCES_DIR__)/$(Build.Repository.Name)
PROJECT_DIR: $(Pipeline.Workspace)/$(PROJECT_DIR_RELATIVE)
File: showProjectInfo.sh
#!/bin/bash
pwd
ls -al
Repo: example-project
File: azure-pipelines.yml
resources:
repositories:
- repository: core_pipeline # Must match `checkout:` in core pipeline repo.
type: git
name: MyAzureDevOpsProject/core-pipeline
ref: master
trigger:
- master
extends:
template: pipeline.yml@core_pipeline # Must match `repository:` above.
(This is the only piece of code duplicated across project repos.)
Problem
The setup described above works well. For example, I can have build validation for pull requests in example-project, and I can trigger pipeline runs manually from the Azure DevOps web GUI. In the latter case, I can optionally select another branch for the core_pipeline repository resource, which is useful for testing changes to the core-pipeline repo before merging them.
However, there is nothing preventing me from merging PRs in core-pipeline without having tested them whatsoever. I have to remember to manually test each project repo against the core-pipeline PR branch before merging the PR, which is somewhat tedious and, above all, very error-prone. There is effectively no protection against making arbitrarily bad changes to the core pipeline, breaking the workflow of all project repos depending on it.
I can add example-project‘s pipeline to the build validation policies for PRs in core-pipeline, but then core-pipeline‘s master branch is used for the validation build, which is useless; the point is to use the PR branch.
Goal
I would like to have a build validation policy for PRs in the core-pipeline repo such that example-project must pass a pipeline run using that PR branch of core-pipeline before the PR can me merged.
It is not necessary that all project repos using the core pipeline repo automatically be covered by said build validation; I’d be perfectly happy if I had to manually select (once) which project repos should be included.
Important note
The core pipeline consists of two equally important parts:
- the YAML template – processed at template compile time, before the pipeline run is started
- the Bash script – cloned at runtime in the
checkout task
Checking out a specific ref using inline syntax, e.g.
- checkout: 'git://MyAzureDevOpsProject/core_pipeline@${{ parameters.ref }}'
path: $(PIPELINE_DIR_RELATIVE)
is not a (complete) solution, because even if parameters.ref can be populated with the name of the PR branch, only the Bash script will be affected; the YAML template will still be from the master branch, not the PR branch.
