Only trigger a release when the build changed

I created a Build task for this purpose as well. Check it out here! 

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.


function Invoke-CheckSameCommitInBuild
{
$CurrentBuild = Get-BuildById -BuildId $currentBuildID
$builds = Get-BuildsByDefinition -BuildDefinitionID $CurrentBuild.definition[0].id
$LatestBuild = $builds.value | Where-Object {$_.result -eq "succeeded"} |Sort-Object {$_.finishtime} -Descending | select -First 1
if ($LatestBuild -eq $null)
{
#No successfull builds found, thus different commit"
Set-BuildTag -BuildID $currentBuildID -BuildTags "Release"
}
if ($LatestBuild.sourceVersion -ne $CurrentBuild.sourceVersion)
{
# Not the same, tag with a Release Tag
Set-BuildTag -BuildID $currentBuildID -BuildTags "Release"
}
}

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)

1

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!

Trackbacks/Pingbacks

  1. Automatically retain a VSTS release – Jasper Gilhuis - July 24, 2017

    […] Interacting with VSTS and the Rest API’s https://roadtoalm.com/2017/05/01/only-trigger-a-release-when-the-build-changed/ […]