Has anyone experienced setting up a build validation pipeline on an Azure DevOps branch, where the YAML is hosted in a different repository than the repository for which the branch policy is set?

Example:

• Repo A - this is where the validation pipeline YAML is stored.
• Repo B, C, D, etc. - this is where the build validation is set on the main branch.

The validation that needs to be performed is exactly the same for the mentioned repositories. Therefore, the reason we want to set it up this way is to avoid each repo B, C, D, etc. having its own YAML file.

We have tried to set up the above, but we are encountering a problem. Although the build validation is correctly displayed for pull requests to the main branch within repo B, C, D, etc., the pipeline is not automatically triggered.

Additionally, the pipeline is not executed when we click the "Queue" button in the PR overview. Simply nothing happens; no pipeline run, no feedback, nothing is visible anywhere, and the button remains clickable (see the image below).

Below a bare-bones examples of the YAML in repo A that reproduces the issue:

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

pool:
  name: 'default'
  
pr:
  branches: 
    include:
      - main

jobs:
  - job: AssertPSRule
    steps:
      - task: PowerShell@2
        inputs:
          targetType: inline
          script: |
            Write-Host $(Build.Repository.Name)

Has anyone experienced setting up a build validation pipeline on an Azure DevOps branch, where the YAML is hosted in a different repository than the repository for which the branch policy is set?

Example:

• Repo A - this is where the validation pipeline YAML is stored.
• Repo B, C, D, etc. - this is where the build validation is set on the main branch.

The validation that needs to be performed is exactly the same for the mentioned repositories. Therefore, the reason we want to set it up this way is to avoid each repo B, C, D, etc. having its own YAML file.

We have tried to set up the above, but we are encountering a problem. Although the build validation is correctly displayed for pull requests to the main branch within repo B, C, D, etc., the pipeline is not automatically triggered.

Additionally, the pipeline is not executed when we click the "Queue" button in the PR overview. Simply nothing happens; no pipeline run, no feedback, nothing is visible anywhere, and the button remains clickable (see the image below).

Below a bare-bones examples of the YAML in repo A that reproduces the issue:

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

pool:
  name: 'default'
  
pr:
  branches: 
    include:
      - main

jobs:
  - job: AssertPSRule
    steps:
      - task: PowerShell@2
        inputs:
          targetType: inline
          script: |
            Write-Host $(Build.Repository.Name)

• git
• azure-devops
• azure-pipelines
• pull-request
• azure-repos

• Do you have protected resources that might require authorization/permissions such as variable groups, environments with approvals, etc? You might need to run the pipelines in repos B, C, D, etc manually at least once, to authorize these resources. – Rui Jarimba Commented Jan 20 at 11:13
• Also, do you have the templates and/or the pipelines in different projects? See Limit job authorization scope to current project. – Rui Jarimba Commented Jan 20 at 11:15
• Good points @RuiJarimba. The templates and pipelines are in the same project, and the pipeline does not use variable groups and environments with approvals etc. I have added a bare-bones YAML template to my original post which reproduces the issues. – Thijmen Commented Jan 20 at 11:30
• "...the reason we want to set it up this way is to avoid each repo B, C, D, etc. having its own YAML file." - I confess I never configured build policies with pipelines without YAML files in the current repository, but I wonder how this really works - for example how does the pipeline in repository A checks out the code in repositories B, C or D? – Rui Jarimba Commented Jan 20 at 11:55
• Good question @RuiJarimba. The primary reason for this is that we want to execute the exact same pipeline steps for repository B, C, D etc. And because of this, if we want to update the pipeline steps, it only has to be done once (in repo A) instead of changing the YAML multiple times (once for every repo B, C, D, etc.). As for checking out the code of the repo, we intend to determine the repo using predefined Azure variables (e.g. Build.Repository.Name or something similar) and then do a manual checkout step. Does this answer your question? – Thijmen Commented Jan 20 at 12:01

1 Answer 1

I do understand the idea and motivation for your approach, but I'm not 100% that will work - the main problem is how to checkout the source code in repositories B, C or D without some hacks or workarounds.

I suggest you create reusable stage or job templates in repository A that can be easily reused in the other repositories. Or, as an alternative, create some sort of base pipeline (using extends templates).

Example of a base pipeline in repository A:

parameters:
  - name: foo
    type: string

jobs:
  - job: AssertPSRule
    steps:
      - checkout: self # checkout the repository that contains the pipeline
      - task: PowerShell@2
        inputs:
          targetType: inline
          script: |
            Write-Host $(Build.Repository.Name)

YAML pipelines to add to repositories B, C, D, etc:

# my-pipeline.yaml

resources:
  repositories:
    - repository: shared
      type: git
      name: A
      ref: releases/1.0.0

extends:
  template: /pipelines/base-pipeline.yaml@shared
  parameters: 
    foo: '123456'