Is it possible to have a yaml pipeline trigger on commits/PRs for branches of different repositories (e.g. Repo A) to the one the azure-pipelines.yaml file is in (e.g. Repo B)?
I'm aware I can build the pipeline against Repo B and have it checkout Repo A using e.g:
resources:
repositories:
- repository: Repo A
type: github
endpoint: ***
name: ***/RepoA
trigger:
- master
But the trigger is only applying to Repo B, i.e. when I make a commit on master to Repo A, the pipeline does not trigger.
The "Sprint 173" release seems to be including the multi-repo triggers feature. I suspect you might be missing the ref.
Here is an example that shows how to define multiple repository
resources in a pipeline and how to configure triggers on all of them.
trigger:
- main
resources:
repositories:
- repository: tools
type: git
name: MyProject/tools
ref: main
trigger:
branches:
include:
- main
- release
The pipeline in this example will be triggered if there are any
updates to:
main branch in the self repo containing the YAML file
main or release branches in tools repo
Unfortunately Multi-repo triggers is supported for Github repo resources yet.
As it is said in the document:
Repository resource triggers only work for Azure Repos Git repositories at present. They do not work for GitHub or Bitbucket repository resources.
If you were using Azure Repos Git repositories. You need to specify the trigger section for the repository resources in order to enable the Multi-repo triggers. See document here for more information.
Since you are using github, you can use pipeline completion triggers as workaround. You can refer to below steps to setup a pipeline completion trigger for RepoB pipeline.
1, Set up the triggering pipeline for RepoA.
You can create a pipeline for github RepoA in azure devops. Classic UI pipeline is recommanded, for it won't add a azure-pipelines.yaml file in your RepoA.
I suggest you add a empty agent job(without any tasks)in the triggering pipeline. So that the pipeline run will always be successful.
You need to Enable continuous integration for this triggering pipeline. So that the commits/PRs for branches in RepoA will automatically trigger this pipeline.
In the pipeline Edit page, Go to Triggers tab, Check Enable continuous integration, Add the branches you want to enable CI in the Branches Filters section
2, Set up pipeline resources in triggered pipeline (ie. azure-pipelines.yaml file for RepoB)
Add the pipeline resources and specify the trigger section in the pipeline resource. See below example:
resources:
repositories:
- repository: Repo A
type: github
endpoint: ***
name: ***/RepoA
pipelines:
- pipeline: repoAPipeline # Name of the pipeline resource
source: triggeringPipeline-RepoA # Name of the triggering pipeline
trigger:
branches:
- releases/*
- master
When changes are made to RepoA, the triggering pipeline will be triggered and complete successfully. When the triggering pipeline is completed, Pipeline for RepoB will be triggered.
By setting up the triggering pipeline for RepoA and the pipeline resources in pipeline of RepoB. You can achieve the same effect with Multi-repo triggers.
Related
trigger:
branches:
include:
- master
tags:
include:
- Showcase
pr:
branches:
include:
- master
the code above is from my yaml azure pipeline with using bitbucket repo. Anytime I do a PR in my bitbucket repository I expect build pipeline to run automatically in azure devops but it's not the case. Currently, I have to run the pipeline manually to complete PR validation. creating pipeline with the same line of code under another repo works correctly. I'm not sure what the problem is.
I created anoter dummy pipeline with a new project, the pr triggered build automatically when pr to the the master. the webhohook seems to be working fine. the trigger option doesn't override the yaml pipeline. I can't think of anything else to check.
I'm trying to set up a pipeline that will trigger, when a commit is made in a repository that exists in a different organization.
In my own org, I've created a git repo with a yaml pipeline file in the main branch.
With the below setup, I can checkout the code from the other organization if I run the pipeline manually. But it is not triggered when a commit is pushed to that repository.
Looking at the documentation, this should be possible?
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/multi-repo-checkout?view=azure-devops#triggers
resources:
repositories:
- repository: OtherOrgRepo # In a different organization
endpoint: OtherOrgConnection
type: git
name: proj/reponame
ref: develop
trigger:
- develop
pool:
vmImage: ubuntu-latest
steps:
- checkout: OtherOrgRepo
The token used for the service connection has full access.
Is this not supported, or am I missing a step?
I guess I just need to read the big blue box:
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/multi-repo-checkout?view=azure-devops#triggers
Repository resource triggers only work for Azure Repos Git repositories in the same organization at present. They do not work for GitHub or Bitbucket repository resources.
I did however manage to trigger a classic pipeline by using a generic Git service connection, which will poll for changes at an interval.
Like many before me I'm struggling hard with configuring pipeline triggers in Azure DevOps.
Background:
single project in the Organization
three branches: main, Infrastructure, Application
The branches are kind of independent of each other. They are never merged into main either.
I have a pipeline which deploys two App Services. The YAML file for this pipeline is in the Infrastructure branch. The Default branch for manual and scheduled builds is set to Infrastructure.
Then I have 2 pipelines, each to deploy a different App to the App Service. The YAMLs for those pipelines are in the Application branch. The Default branch for manual and scheduled builds is set to Application.
By themselves, the pipelines work perfectly fine. However what I am trying to achieve is to trigger the App pipelines after the App Service pipeline finishes. And no matter what combination of settings I try, I can't get it to work.
This is currently how it looks like in the n-th version of the YAML:
name: 'deploy-webapp-002'
pool:
vmImage: windows-latest
resources:
pipelines:
- pipeline: 'Deploy App Services' # Internal name of the source pipeline, used elsewhere within this YAML
# e.g. to reference published artifacts
source: deploy-appservices # Azure Pipelines name of the source pipeline referenced
project: HomeLab # Required only if the source pipeline is in another project
trigger:
branches:
include:
- Infrastructure
- Application
pr: none
trigger: none
Is it even possible to do what I'm trying to do?
If yes, what settings should be specified in the Resources/Pipelines section in the YAML, and how should the Default branch for manual and scheduled builds look like for each of those pipelines?
I can reproduce the same issue when I put the YAML files separately in two branches and set the default branch.
Refer to this doc: Define a pipelines resource
When you define a resource trigger, if its pipeline resource is from the same repository (say self) as the current pipeline, triggering follows the same branch and commit on which the event is raised. But, if the pipeline resource is from a different repository, the current pipeline triggers on the default branch of the self repository.
In your caseļ¼ you are using the same repo. So triggering follows the same branch and commit on which the event is raised.
To solve this issue, you need to copy the YAML file in Application Branch to Infrastructure Branch.
On the other hand, you can also try to set Build completion trigger manually on UI.
For example:
I have a YAML build pipeline which resides on the repo PipelineRepo, branch master.
It contains a reference to a second repo AppRepo with a trigger on branch dev.
When a commit is made on AppRepo/dev, the build triggers and produces an artifact. The Build.SourceBranch predefined variable available during the build is of course dev as this was the triggering branch on AppRepo. This is as per the docs here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/multi-repo-checkout?view=azure-devops#triggers
The specific part of the docs is this:
When an update to one of the repositories triggers a pipeline, then
the following variables are set based on triggering repository:
Build.Repository.ID
Build.Repository.Name
Build.Repository.Provider
Build.Repository.Uri
Build.SourceBranch
Build.SourceBranchName
Build.SourceVersion
Build.SourceVersionMessage
I consume the artifact in a Release pipeline, where I have a "Dev" stage with an artifact filter for branch dev:
I have a continuous deployment trigger on the artifact for branch dev:
Now we come to the problem
Every time a new build artifact is produced from the AppRepo/dev branch, the continuous deployment trigger doesn't fire because it thinks the build branch of the artifact was PipelineRepo/master. This is also true of the artifact filter on the stage - I have tested it by changing the continuous deployment trigger to master.
Note: you can see on the screenshot the build name contains the word "dev". This is because I use the Build.SourceBranch var in my custom build name. This proves the artifact is definitely produced by the AppRepo/dev triggering branch.
How can I get the DevOps Release Pipeline to pick up the triggering branch?
Based on your description, I could reproduce the similar issue in my organization.
When the pipeline is triggered by another repo branch, it still show the master branch in Release artifacts.
At the same time, the display of the trigger branch is also inconsistent in Pipelines.
For example:
Overview:
Detail view:
I suggest that you could create a feedback ticket in Our feedback Site.
For a workaround:
You could add a build tag in Pipeline to distinguish artifacts.
Yaml sample:
resources:
repositories:
- repository: test
type: git
name: 123/ARM
trigger:
- test
steps:
- checkout: test
- script: echo "##vso[build.addbuildtag]$(Build.SourceBranch)"
Release Pipeline:
You could set the master branch and add the build tag.
In ADO, you can create a "repository resource" per this documentation. The "trigger" section allows you to define a CI trigger for any Azure repo in your space. Therefore, given the following config:
Repos:
AzureRepo1 - Contains project files that should be built
AzureRepo2 - Contains pipeline file 'pipeline.yml'
resources:
repositories:
- repository: "Azure_Repo_1"
type: git
name: AzureRepo1
ref: development
trigger:
branches:
include:
- development
- staging
- production
pool:
vmImage: 'windows-latest'
jobs:
- template: Template.yml
parameters:
service: "development"
run_tests: true
When I make a change to AzureRepo1, the pipeline triggers. At runtime, how would I determine which branch ("production", "staging", or "development") of the target repo (AzureRepo1) triggered the build? Ideally, the "service" parameter being fed into the example template would dynamically reflect which branch triggered the build.
Note: "Build.SourceBranch" and "Build.SourceBranchName" seem to pull the branch from the repo that hosts the YML file (in this case, AzureRepo2).
I was wrong. These function as intended. Use the below solution.
According to documentation here:
When an update to one of the repositories triggers a pipeline, then the following variables are set based on triggering repository:
Build.Repository.ID
Build.Repository.Name
Build.Repository.Provider
Build.Repository.Uri
Build.SourceBranch
Build.SourceBranchName
Build.SourceVersion
Build.SourceVersionMessage
For the triggering repository, the commit that triggered the pipeline determines the version of the code that is checked out. For other repositories, the ref defined in the YAML for that repository resource determines the default version that is checked out.
If triggers happens on AzureRepos1 you should have correct branch name in Build.SourceBranchName