Set custom build name from YAML pipeline

05 Oct 2022

Azure DevOps build and release pipelines automatically creates a build name based on the current unique build Id for your project. These build Ids aren't relevant to whatever you do in your project, so it doesn't mean anything to the developers. So, modifying the build name dynamically based on a feature name and version name offers a better understanding of the build or release to the team.

The following snippet shows how to follow semantic version numbers for your builds. Here major and minor versions are hard-coded in YAML so that we can maintain different version numbers on different feature branches. This allows multiple teams to work on different product versions simultaneously. 

YAML pipelines offer you a simple counter variable, that gets incremented during each run. This helps your team to see the number of build iterations that have gone before you are ready with the release of a feature. 

Once you are ready with the semantic build number, add a PowerShell script task to override the Visual Studio Online property i.e.,"##vso[build.updatebuildnumber]$buildName" with the custom build name. On your next building you'll notice the custom build name appearing in the Pipeline runs and your team will be comfortable to know what is being built and what was part of a particular build (e.g., feature or change that is part of the major.minor version).

trigger:
  batch: true

variables:
  # Agent VM image name
  vmImageName: 'windows-2022'

  version.Major: '1' # Manually adjust the version number as needed for semantic versioning. Revision is auto-incremented.
  version.Minor: '10.0' # Manually adjust the version number as needed for semantic versioning. Revision is auto-incremented.
  version. Revision: $[counter(variables['version.Minor'], 0)]
  versionNumber: '$(version.Major).$(version.Minor).$(version.Revision)'
  versionNumberAlpha: '$(versionNumber)-alpha'
  versionNumberBeta: '$(versionNumber)-beta'
  versionNumberRC: '$(versionNumber)-rc'
  publishArtifact: '0'

  # Working Directory
  buildConfiguration: 'release'
  buildPlatform: 'any cpu'

stages:
- stage: Build
  displayName: Build stage

  jobs:
  - job: Build
    displayName: Build
    pool:
      vmImage: $(vmImageName)

    steps:
    - task: PowerShell@2
      name: BuildInfo
      displayName: Set the name of the build (i.e. the Build.BuildNumber)
      inputs:
        targetType: 'inline'
        script: |
            [string] $buildName = "$(versionNumber)"
            Write-Host "Setting the name of the build to '$buildName'."
            Write-Host "##vso[build.updatebuildnumber]$buildName"
            $branch = $Env:BUILD_SOURCEBRANCHNAME
            $publishArtifact = $Env:PUBLISHARTIFACT
            if (($branch -like "H_*") -or ($branch -like "R_*")) {
              $publishArtifact = '1'
              Write-Host "Allow publishing the build artifacts for '$branch'."
            }
            Write-Host "##vso[task.setvariable variable=publishArtifact]$publishArtifact"
            Write-Host "##vso[task.setvariable variable=canDeploy;isOutput=true]$publishArtifact"

There are couple of additional things shown in above script, that allows you to set a new variable "publishArtifact" only for particular branch names. And with this variable value you can skip certain tasks that aren't relevant for a particular branch. e.g., you don't want to create artifacts for the individual story branches but you want the dev to test his code quality, security etc., through the well-defined build steps.