I'm hoping to somehow replicate the functionality of PR triggers which, according to the docs, are currently only supported for GitHub and Bitbucket Cloud repos. I'd like my CI pipelines to not trigger if the change is incoming from certain branches.
I've mostly tried to solve this problem with GitVersion, which is the part of my pipeline that makes it problematic to trigger builds when I'm merging back from a release build or master back onto develop. So far I've had no luck, so now I'm hoping I've overlooked a feature of Azure Pipelines which will help.
My current pipeline trigger:
trigger:
batch: true
branches:
include:
- develop
paths:
exclude:
- ReadMe.md
- development-pipeline.yml
- release-pipeline.yml
- GitVersion.yml
I'd like a pull request which originated in a release branch (can be identified with the regex pattern [Rr]eleases?[\/-]) or master to not trigger my pipeline. In reality, any change to the develop branch triggers the build.
If you just want the develop branch not to trigger ci build, then you can check "Enable continuous integration" option in the Continuous integration of builds Triggers and set exclude develop branch in the branch filters.
If you want some source branches to trigger the CI build of the develop branch, some can't. I am afraid that this feature you want is not achievable. Once your deveop branch
Enable continuous integration, then the deveop branch will trigger the build pipeline once it changes.
If you want to merge the commits on the release or master branch into the develop branch, and create pr does not trigger the CI build, you could enable the build policy in the Build validation in the branch policy.In this way, only after PR is completed will CI build be triggered.But pr build is unavoidable.
Related
In Azure Devops, I have a repo that's in Bitbucket. I'd like to trigger a package publish on every approved pr that gets merged to the develop branch.
I've figured out how to conditionally run a task if the build is a pr or not, and how to trigger if the pr is to develop, but that means that the task is run for every PR created to develop. I'd like the task to only run when the pr has been merged to develop.
I noticed the following variables in my pipeline:
SYSTEM_PULLREQUEST_ISFORK=False
SYSTEM_PULLREQUEST_MERGEDAT=
SYSTEM_PULLREQUEST_PULLREQUESTID=139
SYSTEM_PULLREQUEST_PULLREQUESTNUMBER=139
SYSTEM_PULLREQUEST_SOURCEBRANCH=source-branch
SYSTEM_PULLREQUEST_SOURCECOMMITID=e55835e7e2e65ad87fd09a03959fefcfcc4d475f
SYSTEM_PULLREQUEST_SOURCEREPOSITORYURI=[repoURL]
SYSTEM_PULLREQUEST_TARGETBRANCH=develop
And the SYSTEM_PULLREQUEST_MERGEDAT= variable stood out. Anyone have suggestions? Am I overly complicating this?
It is possible to achieve this with just conditions. Let's say you were merging from feature branch to develop branch. And you only want a task to be executed when the pr has been merged to develop.
First of all you should know the default CI triggers and PR triggers for Bitbucket repository on Azure pipeline.
1, CI triggers
If you don't specify any triggers, the default is as if you wrote below, which means commit to any branch will trigger the pipeline.
trigger:
branches:
include:
- '*'
When you specify a trigger, it replaces the default implicit trigger, and only pushes to branches that are explicitly configured to be included will trigger a pipeline. Includes are processed first, and then excludes are removed from that list.
2, PR triggers
If no pr triggers appear in your YAML file, pull request validations are automatically enabled for all branches.
When you specify a pr trigger, it replaces the default implicit pr trigger, and only pushes to branches that are explicitly configured to be included will trigger a pipeline.
Each new run builds the latest commit from the source branch of the pull request. This is different from how Azure Pipelines builds pull requests in other repositories (e.g., Azure Repos or GitHub), where it builds the merge commit,
See the document for more information.
So if you don't specify any CI triggers or PR Triggers. The default behavior is to enable the triggers for all branches. And the PR triggers will only trigger the pipeline to build the last commit from the source branch(ie. Feature branch) instead of develop branch.
So it will explain why there are two triggered builds on an update to a pr. one is CI trigger(ie. IndividualCI), another is PullRequest. Both builds were against the source branch (ie.feature).
When the pr was merged to develop. what happened was a new commit being added to develop branch, which will trigger the CI build. So the task you want to trigger should be run against develop branch.
As for above case of yours. I suggest you disable the pr triggers and only enable the CI triggers.(for pr triggers will only build the latest commit from the source branch, which is the same with CI trigger. )
You can disable the pr trigger like below:
pr: none
So you can just set the condition like below for the task
- task: taskname
input:
condition: and(eq(variables['Build.SourceBranchName'], 'develop'), eq(variables['Build.Reason'], 'IndividualCI'))
You can also use Webhook to trigger the azure pipeline. And set the condtion to eq(variables['Build.Reason'], 'ResourceTrigger')
resources:
webhooks:
- webhook: bitbucketwebhook
connection: bitbucketwebhook
Please see this thread for more information.
We are in the process of configuring GitFlow branching where we want to trigger PR validation pipeline when a PR is created on release/* branch after our features in develop branch are ready to move on to next stage. As per Azure DevOps, we need to setup build validation pipelines in branch policies which is per branch. We want to archive our release branch after each release and use new release branch with same pattern i.e release/* in the next release .
As far as i know , we will have to create branch policy and multiple configurations within it every release for the newly create release branch ? Is this correct ? :(
I found that we can override Azure pipelines trigger from the UI and there we can have Branch filters and i was able to add release/* but that will be a CI pipeline and won't act as a validation pipeline on PR to release/* branch ? Is this correct ? :(
Is creating PR & doing PR validations for release/* a wrong approach ? :(
How are you folks doing gitflow in Azure Devops ?
You can create a branch policy for the wildcard release/* and it will be for all future releases branch.
In Azure DevOps, the /* represents as a folder so go the folder (in the Branches page), click on the ... dots, and "Branch policies".
You can see there that the policy of for the wildcard:
I am working on an Azure pipeline for a dotnet core project that runs on Windows Self hosted agent.
I want my pipeline to use Git commands to check out the release branch and merge the develop branch into it. Next steps will be to build the release branch and deploy to intranet servers
I don’t know Git wording very good, I was using TFS for years. I use the commands below and got the logs here:
- task: CmdLine#2
displayName: Checkout Release branch
inputs:
script: |
#echo off
git checkout release
git pull develop
git status
From the logs, I understand:
It downloads the content of the develop branch because it is the default branch in GitHub, I’d rather want the release branch but I believe Azure is like that
I manage to switch to release but I have these errors that I don’t understand:
##[error]Previous HEAD position was bc94bd2 Update Staging Build Pipeline.yml
##[error]Switched to branch 'release'
I understood that pull can be used with local or remote branch so I use it to fetch and merge the develop branch to the release branch but I get: [error]fatal: 'develop' does not appear to be a git repository
Do I have to specify credentials on every calls to git?
On the last step, it fetches again the code from the develop branch and I understand why
If you could help me improve my script, that would be great,
Many thanks.
You can use git merge commands to merge branches. To merge develop branch into release branch you can use git merge origin/develop. Check the document for more information. See below example:
steps:
- checkout: self
persistCredentials: true
- task: cmdLine#2
inputs:
script: |
#echo off
git checkout release
git merge origin/develop
git status
However, it is not recommended to deploy release branch in above way. You can change the default branch of your azure pipeline to release branch and enabled the Continuous Integration trigger for release branch.
So that you can create a pull request to merge develop into release from the github UI or by using commands. After develop is merged into release, the azure pipeline will be automatically triggered to deploy from release branch. Note: the azure pipeline yaml file must exist in release branch too. See below steps:
1, To change azure pipeline branch from develop to release:
On your azure devops pipeline Edit page, Click the 3dots and click Triggers
Go to YAML tab--> Get Sources-->Click the 3dots to change the default branch.
2, Set CI trigger for release branch
In the azure pipeline yaml file, set the trigger to include release branch(You can also set PR trigger):
(Actually you do not need to follow above steps to change the default branch. You just need to include the azure pipeline yaml file in release branch and set the CI trigger to include release branch as below)
trigger:
branches:
include:
- release
exclude:
- develop #if you want disable CI trigger for develop branch
By adding the CI trigger to include the release branch in the azure pipeline yaml file. Azure pipeline will automatically be triggered on release branch when merging from develop into release branch.
I want to use both CI-triggers and PR build validation in Azure DevOps. The goal is that as long as no PR has been created (and published) for a feature/topic-branch, the CI triggers should ensure that the branch gets built (so that developers get early feedback). I configured the following in the Pipeline (yaml):
trigger:
branches:
include:
- chore/*
- feature/*
- fix/*
- refactor/*
paths:
include:
- frontend/*
...
This works well. I further configured PR build validation under branch policies. The problem is that two builds are triggered now: the CI build and the PR build. Since we often update PRs multiple times to fix issues found during the code review, building everything twice isn't really what we need.
Is there any way to configure that CI builds are only triggered if there's no PR build for the same push?
This is not possible. They are totally separated triggers not aware of each other.
But you can achiever your result in a slightly different way. If you have branch policy configured and you sleect there a build you can set pr: none in you yaml definiton. It will block PR build, leaving CI build as they are. And this CI build will be considered as condition for you branch policy check.
Selecting this checkbox you will get list of builds which you may select as required
My Ci trigger build
PR view:
If I understand the question correctly add:
trigger: none
In your CI pipeline. This will have the PR kick it off via branch policy. Your CD pipeline will be triggered when the merge into master happens.
If you are using the Azure DevOps Repo, then the PR build is controlled by branch policies, but the CI-trigger (in azure-pipeline.yaml) has nothing to do with this branch policy.
So if you want both build validation for PR and the CI build at the same time, then every time you push your changes to update a PR, duplicate pipeline builds would be unavoidable. It is a side-effect.
I have my git repository hosted on Azure DevOps. I created a new yaml based build pipeline in the master branch and have set the trigger section to two existing branches. Other branches don't have a azure-pipeline.yml file nor any kind of branch policies are set for this DevOps project.
trigger:
batch: 'true'
branches:
include:
- master
- develop
The trigger gets invoked for every change in the master branch as expected. But is ignoring any pushes to the develop branch.
If I configure a build pipeline with the visual editor and define the exact two branches there, for every push a build will be triggered.
Any idea how Azure Pipeline respects the build definition also for other branches without copy and pasting the whole definition for every possible branch?
Build trigger is not invoked on push for Azure Git repositories
I have created a sample with the syntax:
trigger:
batch: 'true'
branches:
include:
- master
- Dev
And it works fine on my side. Then I check the new project you provided, but I found that the .yml file is incomplete and does not contain a trigger: node.
So, to resolve this issue, we need to double check the .yml file you modified in under the master branch, and you build .yml file is you modified.
Besides, when we edit the build pipeline, there is a extended button, we could select the option Triggers to set the build trigger with visual editor:
If above not help you, you can try to create a new build pipeline, set the trigger only with Develop branch, check if it works fine, then return to the previous with master
and develop branch.
If all of the above methods are not worked, you may need share a detailed sample and some steps, the reason for this problem may be hidden in the corner we ignore.
Hope this helps.