Hello!

I’ve been trying to wrap my head around how to get the Build Number to display in the environments status information in Azure DevOps. Environments use the Build Number to show which pipeline was last deployed. And so there is a distinction between a build number, which can include info like app name and branch name, and the semver number, which can be included with the build number. However the semver can be used when publishing artefacts from a pipeline, which doesn’t need all the info included in the build number: PowerShellGallery has strict versioning rules, and I don’t know about Pypi, but the convention is to use semantic versioning.

For much of my projects I have used the logging command updatebuildnumber in Azure DevOps. The example below is from bobojojo azure devops yaml file A version number is defined as a variable, and a counter expression is used to increment the patch number. This is then used as part of the build number, and this works all very well.

variables:
  - name: BaseVersionNumber 
    value: "0.4"  
  - name: Minor 
    value: $[counter(variables['BaseVersionNumber'], 1)]
  - name: VersionNumber 
    value: $(BaseVersionNumber).$(Minor)
  
steps:
  - task: PowerShell@2
    displayName: "Update Build Number"
    inputs:
      targetType: 'inline'
      script: |
          $BuildName = $env:BUILD_DEFINITIONNAME +'_'+$env:VERSIONNUMBER +'_'+ $env:BUILD_SOURCEBRANCHNAME 
          Write-Host "##vso[build.updatebuildnumber]$BuildName"

The versionnumber var is then passed in when running vsce to generate the theme:

  - task: Bash@3
    displayName: "Package and Publish VS Code Theme"
    inputs:
      targetType: 'inline'
      script: |
        npm install -g [email protected]
        echo $PAT
        git config user.email "[email protected]"
        git config user.name "RichieBzzzt"
        sudo npm install -g vsce
        vsce package
        vsce publish $(VersionNumber) -p $PAT
      failOnStderr: false
      workingDirectory: $(System.DefaultWorkingDirectory)
    env:
      PAT: $(POSTMAN)

So far, so boring.

However, if I were to use the same process and include an environment in a process like this, the status page would not use the build number set, but instead the default build number for all builds, which is $(Date:yyyyMMdd).$(Rev:r). This lack of correlation is troubling, and looks unprofessional!

I have created a GitHub project and a public Azure DevOps project shows the options to solve this. I’ll go into detail each method in upcoming posts.