Today was my lucky day. I finally found a solution for a problem I had for a long time. It was thanks to a colleague(thanks Ben) that I finally was able to fix it. Let me explain the issue...
On one of my projects I had two Azure DevOps YAML pipelines configured:
- A Continuous Integration(CI) pipeline that is triggered for every check-in into master.
- A Continuous Deployment(CD) pipeline that is triggered once the CI pipeline completes and deploys the applications to multiple environments.
To make this possible I’m using a pipeline trigger in the CD pipeline that is linked to the CI pipeline:
Just for completeness, here is the trigger configuration for the CI pipeline as well:
The problem I encountered was that every time some code was checked into the master branch both the CI and CD pipeline were triggered! Of course this is not wat I wanted as only the CI pipeline should run and only when the CI pipeline successfully completes, the CD pipeline should start.
The workaround
I had a workaround in place to solve the issue above but I didn’t like it.
Let me first explain the steps for the workaround:
- I opened the pipeline in Azure DevOps in Edit Mode and clicked on the triple-dot button on the right:
- I choose Triggers from the dropdown to open the Trigger settings for the pipeline. As you can see Continuous Integration is Enabled here.
- On the right, I checked the ‘Override the YAML continuous integration trigger from here’ checkbox and selected the ‘Disable Continuous Integration’ option.
This solved my problem but I didn’t like the solution because it beats the whole point of having a YAML file. I prefer to have all the relevant pipeline information there and not inside a hard to discover setting in Azure Devops..
The final solution
Today I was sitting next to my colleague Ben and when I explained the problem to him, he suggested me the final solution. I need to add an extra ‘trigger:none’ at the top of my CD YAML file. The ‘trigger’ value that is already there is only applicable at the Pipeline Resource trigger level. I wasn’t aware that a second trigger is defined at the full pipeline.
Here is the fix:
Thanks Ben for the solution!