Dynamically Rename your Azure DevOps Pipeline Builds

Search for a command to run...

No comments yet. Be the first to comment.
In the third and final part of our Azure Conditional Access Policies as Code with Graph API series, we'll be covering the Apply phase of our policies. You can check out the other parts from the links below: Part 1: Write Part 2: Plan Part 3: Apply...
In the second part of our Azure Conditional Access Policies as Code with Graph API series, we'll be covering the Plan phase of our policies. You can check out the other parts from the links below: Part 1: Write Part 2: Plan Part 3: Apply Now tha...
Conditional access is an additional layer of security whereby it looks for signals and makes a decision on which actions the user must complete in order to access a resource. Typically conditional access policies are manually managed in Azure AD thro...
In this blog post I'll take you through this Terraform module I created which you can use to deploy VNet peerings in your Azure tenant. Consider a typical hub and spoke network, the Virtual Networks may be spread out across your tenant in multiple su...
When you deploy your infrastructure with Terraform, the state is recorded to map the resource instances to the configuration. When the configuration is updated, Terraform looks at the current state and then creates a plan to update or delete the reso...
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>
First set the build name to the variable BuildName like so. This will be dynamically updated with the pipeline script.
---
name: $(BuildName)
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
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.
Upon PR, build runs as shown

PR merged to master


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 -> https://github.com/rahman124/aqibrahmancom-examples/tree/main/ADO-Build-Naming