Currently I am working on some build and release pipelines to deploy some websites automatically. I have some CI builds running, and some scheduled buils that are deployed automatically. This works fine, but there is some waste in the process.
My CI build is the same as my scheduled build, with 1 major difference. I do not want to start a deployment pipeline for my CI builds, but I do want that for manual and scheduled builds. But how can I distinguish between the 2 builds triggers? I can only configure Continuous Deployment on a Build Definition and not on a trigger.
But there is a solution! Use the tags on a build definition to steer the Continuous Deployment.
Modifying the Build
The build definition can be configured to be a scheduled build, or a CI build, or, of course, a manual build. On the MSDN (docs) page of predefined build variables, the variable $(Build.Reason) is mentioned. But unfortunately, this does not work :-(. Luckily for us, we have the REST API that we can use to reach our goal.
First, I use the REST API, to get the build details, the response JSON contains a field “reason”. The reason is “manual”, “scheduled” or some other value.
Then, I set the Build Tag to this specific value. You can write an output variable and use this in a subsequent task (for example the Add Build Tag Task, found here) or just write the Tag directly in the powershell script using the REST API to write a Tag.
I described both options in earlier posts.
Modify the Release
When you updated the build to set the Tag, you can then create or update the Release trigger, to only listen to builds with a certain tag
For people who are interested, I created a Powershell script that you can use within your build pipeline and that sets that Tag of the build to the trigger.
Add this script to your pipeline and call it using the $(Build.BuildId) parameter and you’re all set !