Using CI triggers and PR build validation together: Prevent that build runs twice

Viewed 812

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?

3 Answers

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 enter image description here

My Ci trigger build enter image description here

PR view: enter image description here

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.

Related