After migrating a Azure DevOps project from one organization to another, I ran into an issue where the automatically generated build identifiers were out of sync. What do I mean by that? Well, in the old organization, the most recent build id was something like 14928
. In Azure DevOps, every build has two primary identifiers, Build.BuildId
and Build.BuildNumber
:
Build.BuildId
: The ID of the record for the completed build.Build.BuildNumber
: The name of the completed build, also known as the run number.
It is possible to specify what is included in the run number by leveraging any of the predefined tokens. The default value for run number is $(Date:yyyyMMdd).$(Rev:r)
.
The easiest way to customize the build/pipeline run number is to specify the name
property at the root level of the YAML file, and in my pipeline I had it define this way:
|
|
This basically uses the BuildId
which is an integer as the BuildNumber
and shows up this way in the pipeline history:
This also allows me to reference the build number either during the build process or the release process:
Now, the issue I was facing was that I simply needed to add the number 14928
to my BuildId
and use that as my BuildNumber
. Unfortunately, Azure Devops does not support mathematical calculations at this stage of of the release pipeline process. As it turns out, mathematical calculations can only be done in tasks running on an agent.
So, with the help of Stack Overflow, this is the solution I eventually came up with:
- Create a pipeline variable to hold your base build number.
- Add a task to add the base build number to the current build id.
- Set the build number to the calculated value
|
|
Hope that proves helpful to you too, dear reader.
References:
Use predefined variables
Arithmetic - Bash Scripting Tutorial
Argument string to integer in bash
Build variables (DevOps Services)
Azure devops - build number vs build id
UpdateBuildNumber: Override the automatically generated build number