Hello!

Argh! Yaml! OK, let’s get something totally clear: I really don’t care for YAML pipelines. I get that the idea behind them is so that the pipelines to take the code from source and deploy up to produciton is stored with the source control. And as someone who places a great deal of importance in source-controlling as much as possible, this dislike of yaml-based pipelines might seem something of a surprise. But part of my issue is that we had the capability of sourcce-controlling pipelines years ago with MSBuild proj files. You could orchestrate entire releases using a combination of MSBuild and a scripting language of your choice.

But then sometime around 2013 all this changed, in the Microsoft eco-system anyway: InCycle’s Release Management was purchased by Microsoft and quickly tacked onto the 2013 release of Visual Studio. It wasn’t widely used and other products were light years ahead of Microsoft anyway in terms of delivering a UI-based experience for automating builds and releases.

Fast forward again to 2016 and Visual Studio Online, or Visual Studio Team Services as what is now known as Azure DevOps was previously known as, and we had very pretty UI clicky and draggy droppy release pipelines. Great. Much quicker to create pipelines. And then you could clone a pipeline and fill in a few blanks. Excellent! But now in the year 2020 we’ve gone forwards by going backwards and using YAML. And unlike other UI-based experiences like ADF, you can’t grab the whole pipeline out of the UI editor into a file to store: you have to take constituent parts to put yaml pipelines together. And YAML is much harder to read than a UI. And secret variables still need to be configured in the UI, for obvious reasons. So you’re note really any further away from the UI.

Despite all this, YAML pipelines are here to stay, and so I’ve been using them on a few projects. And what I wanted to do was to format the build name (rather confusingly referred to as the “BuildNumber”). And so with Dreepy, up until today anyway, the build name has been the name of the project plus the pre-defined variable buildID.

name: Dreepy_$(BuildID)

But now I’ve added a step that calls one of the built-in AzDo logging tasks to update the build number. So to be clear on this: you cannot set the build name to what you want it to be, you have to update the build number to what you want it to be. We never had these problems with UI builds I might add…

variables:
- name: baseVersionNumber
  value: '0.885'
- name: Minor 
  value: $[counter(variables['BaseVersionNumber'], 8)]
- name: VersionNumber 
  value: $(BaseVersionNumber).$(Minor)

#some code ommited

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"

So now when I run a pipeline I get a better formatted name:

The whole of the yaml file used deliver Dreepy is part of the repo on GitHub.