Dynamically Rename your Azure DevOps Pipeline Builds

Dynamically Rename your Azure DevOps Pipeline Builds

Here's a cool way you can dynamically rename your Azure DevOps pipeline build runs.

When you have a pipeline that runs often, it can be confusing navigating through the various builds to find out which did what.

By default the value for the build name (referred to as the build number in docs) is $(Date:yyyyMMdd).$(Rev:r). $(Date:yyyyMMdd) obviously being the date and $(Rev:r) being every revision of the run, so the first will be 1, second 2 and so on.

Consider a pipeline that runs some Terraform, it would be good to see what action Terraform is taking (plan, apply, destroy etc.) and what environment it is running it against (nonprod, prod, etc.)

Let's implement this such that when a PR is raised and a plan is run, the UI displays something like plan - <environment> and upon PR merge, Terraform applies and the build name changes to apply - <environment>

Build Name

First set the build name to the variable BuildName like so. This will be dynamically updated with the pipeline script.

---
name: $(BuildName)

Parameters

If you haven't already, create some parameters for your pipeline. This helps to keep your code DRY and in this case you can use it to manually run your pipeline with specific values passed in. For example:

parameters:
  - name: Action
    displayName: Action
    type: string
    default: 'Plan'
    values:
    - Plan
    - Apply

  - name: env
    displayName: Environment
    type: string
    default: 'All'
    values:
    - All
    - Sandbox
    - Non-prod
    - Prod

Script

Now that we've got some parameters, let's incorporate the script at the start of our pipeline that will rename our builds. We'll use the Azure PowerShell task for this.

- stage: init
  displayName: Initialisation
  jobs:
    - job: init
      steps:
        - task: PowerShell@2
          inputs:
            targetType: 'inline'
            script: |
              $reason = @('BatchedCI', 'IndividualCI', 'Schedule')
              if ($reason -contains $env:BUILD_REASON -Or '${{ parameters.Action }}' -eq "Apply")
              {
                $tfAction = "Apply"
              }
              else
              {
                $tfAction = "Plan"
              }
              echo $env:BUILD_REASON
              echo $tfAction
              echo '${{ parameters.env }}'
              $environment = (echo '${{ parameters.env }}')
              $BuildName = ($tfAction + " - " + $environment)
              Write-Host "##vso[build.updatebuildnumber]$BuildName"
      displayName: Update Build Name

Build.Reason is one of many predefined variables in Azure DevOps pipelines. Predefined variables are automatically set by the system and read-only.

You can reference this as an environment variable so for example Build.Reason becomes BUILD_REASON.

An array, reason, is set containing some different build reasons when the pipeline is automatically triggered, namely when a PR is merged to the main branch. Then there is a conditional to set the variable tfAction accordingly.

Our pipeline name which was set to the variable BuildName gets updated once the script has finished.

Result

Upon PR, build runs as shown

ado-build-plan.png

PR merged to master

ado-buildname-change.png

ado-build-apply.png

Cool, I hope that has been insightful, do have a look at the different predefined variables you can use and experiment with what best suits your environment.

Example configuration on my GitHub -> github.com/rahman124/aqibrahmancom-examples..