Only trigger a release when the build changed

01 May, 2017
Xebia Background Header Wave

Back in the early days, when we used XAML builds in TFS (wow that seems like ages ago!), we had the possibility to NOT execute a build when nothing changed in the source code repository. This checkbox “Build even if nothing has changed” does not exist anymore in VSTS.
For me this is not a real problem, when you build your source code, it is also a validation if your underlying system is OK. It is more a problem when you automatically trigger a release pipeline after a nightly build. Why should you release a new version of your application, when it is not a new version but exactly the same version. Of course, we can discuss that it should not be a problem, that you should always be able to release, but still. It is unneccessary and sometimes even not wanted.

To overcome this, I created a small script and process to solve this issue.

  • The build is triggered nightly. I cannot stop this otherwise than a manual trigger
  • In this build I check if the CommitID that triggered the build is the same as the CommitID in the latest succesful build of the same definition
  • If it differs, I tag my build with a Tag. In my case “Release”
  • I set up my release pipeline to only release the build with this tag

The script
On my GitHub Repository you can find the whole script but I’ll talk you through some parts.
In this snippet, you can see that I first get the details of my current build. I retrieve this build by it’s ID. I sent this from my build pipeline where I use the Predefined Build Variable $(Build.BuildID)


Then I, use the Build Definition ID, to retrieve all the builds with the same definition and filter on only succeeded builds and take the latest.
Then I check the sourceversion, which is the CommitID and check if it is the same. If not, I tag the build with a Release Tag
Set up the pipeline
Then, in the Release Pipeline that deploys this build, I set up the trigger Tag, so that it only releases builds with the right trigger. I’ve described that in my previous blog post 
That’s it!. Now you can safely have a scheduled build and not worry about duplicate releases !
Full source can be found here!


Get in touch with us to learn more about the subject and related solutions

Explore related posts