Get the branch that triggered the pipeline in azure pipelines - azure-devops

I've an azure yaml based pipeline that has a CI trigger with a branch pattern filter. How can I get the name of the branch that has triggered the pipeline?
Pipeline looks like this -
parameters:
- name: TargetBranch
displayName: Target Branch
type: string
default: main
resources:
repositories:
- repository: <reponame>
type: git
name: <reponname>
ref: refs/heads/main
trigger:
branches:
include:
- es/branchtype1/*
pool:
<rest of the yml here that requires the branch name that triggered the pipeline>
There can be many branches with es/branchtype1/* name(created on daily basis). Whenever there
is a push to any of these branches, this pipeline gets triggered. I need to get the name of the branch on which the push was made.

You can use the Build variable Build.SourceBranch.
The branch of the triggering repo the build was queued for. Some examples:
Git repo branch: refs/heads/master
Git repo pull request: refs/pull/1/merge
TFVC repo branch: $/teamproject/main
TFVC repo gated check-in: Gated_2016-06-06_05.20.51.4369;username#live.com
TFVC repo shelveset build: myshelveset;username#live.com
When your pipeline is triggered by a tag: refs/tags/your-tag-name
When you use this variable in your build number format, the forward slash characters (/) are replaced with underscore characters (_).
Note: In TFVC, if you are running a gated check-in build or manually building a shelveset, you cannot use this variable in your build number format.
More information: Use predefined variables - Build variables (DevOps Services)

Related

is there any way to select branches from multiple repositories in CI build

I have trigger in azure-pipelines.yaml like below.
resources:
repositories:
- repository: APPLICATION
type: git
name: AAA/APPLICATION
ref: master
- repository: TESTS
type: git
name: AAA/TESTS
ref: master
STAGES:
- stage : BuildApplication
// checkout branch & build necessary things
- stage : BuildTests
// checkout branch & build necessary things
Since the yaml resides in Application repository, While creating manual CI build I am able to select the Branches in Application repository & for Tests repository the branch checkout will be master always.
is there any was I can able to set the branch details of Tests repository before creating release ?
Is there any was I can able to set the branch details of Tests repository before creating release ?
From your YAML sample, you need to select the Resource Repo branch when manually running the pipeline.
I am afraid that there is no out-of-box method can select the resource repo branch. The branch is defined at resources field. When you running the pipeline, it will use the default branch.
For a workaround, you can change to define the repo in check out field. You can use paramter to define the repo branches and then you can select the branch when you running the pipeline.
Refer to this doc: Inline syntax checkout
Here is an example:
parameters:
- name: test
values:
- refs/heads/main
- refs/heads/test1
pool:
vmImage: ubuntu-latest
steps:
- checkout: git://azure/Repo13#${{ parameters.test }}
Result:

Triggering an Azure pipeline from a repository in a different organization

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.

DevOps YAML build pipeline multi-repo trigger branch not identified by Release Pipeline for continuous deployment trigger or artifact filter

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.

Determining the triggering branch with a multi-repo CI setup in Azure Devops

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

Azure Devops YAML Pipeline Trigger on different repositories

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.