VSTS/Azure DevOps: Auto-Increment NuGet Package Version on Pack

Question

Running the .NET Core Pack task, how do I get the outputted NuGet package version to auto-increment itself?

So, for example, if my current version is 1.0.0, then the next time I call the Pack task, I would like to see 1.0.1.

I'm using environment build variables with Build.BuildNumber and getting outputs at the moment of e.g. 20180913-.2.0, etc. I would like to establish to a more traditional versioning system.

Answer 1

From the docs, the variable Rev:.r is the daily build revision count. The accepted "solution" would lead to one day finishing having a version of 1.0.12, then the next day it will be 1.0.1.

If you want a simple incremental and unique semver, use 1.0.$(BuildID).

$(BuildID) is an internal immutable counter for your builds, and thus far cleaner than $(BuildNumber).

---

BuildID will always be incrementing - no reset. Thus after a minor bump, you'd end up having say 1.2.123 becoming 1.3.124.

If you want to perform this task well, this can be done using npm version or similar, such as pubspec_version for Dart or Flutter builds.

- script: npm version $RELEASE_TYPE

where $RELEASE_TYPE is a variable you can set based on build (ie: CI, PR etc), having a value of major, minor, patch, prerelease etc.

- script: npm version $RELEASE_TYPE
  condition: startsWith(variables['build.sourceBranch'], 'refs/head/release/')
  env:  
    releaseType: minor

---

Update: Bump Repo Version and Use In Build (using npm)

To have the repo version update, I ended up including npm version as a DevDependency, with it's precommit hook to bump the project version on any commit.

This technique can be applied to other project types, placing them in a subfolder - although can lead to complications with server OS requirements.

To use this version in your build, add this bash script task, which gets and exports the version as a task variable:

v=`node -p "const p = require('./package.json'); p.version;"`
echo "##vso[task.setvariable variable=packageVersion]$v"

---

.Net Core Task only version

Unfortunately, no repo-bump.

jobs:
  - job: versionJob #reads version number from the source file
    steps:
      - powershell: |
          $fv = Get-Content versionFile
          Write-Host ("##vso[task.setvariable variable=versionFromFile;isOutput=true]$fv")
        displayName: 'version from file' 
        name: setVersionStep  


  - job: buildJob # consumes version number, calculates incremental number and set version using assemblyinfo.cs
    dependsOn: versionJob
    variables:
      versionFromFile: $[ dependencies.versionJob.outputs['setVersionStep.versionFromFile'] ] # please note that spaces required between $[ and dependencies
      buildIncrementalNumber: $[ counter(dependencies.versionJob.outputs['setVersionStep.versionFromFile'],1) ] #can't use $versionFromFile here


    steps:
      - powershell: |
          Write-Host ($env:versionFromFile)
          Write-Host ($env:versionFromFile + '.' + $env:buildIncrementalNumber)
        displayName: 'version from file output' 

This post describes a couple of others, using version-prefix and automatically applying the BuildNumber as a version-suffix.

Answer 2

I may have figured it out. For anyone tearing their hair out, try this:

Pack Task:

• Automatic Package Versioning: Use an environment variable
• Environment variable: Build.BuildNumber

Then, up in the top menu where you have Tasks, Variables, Triggers, Options, click Options and set:

• Build number format: 1.0$(Rev:.r)

Save and queue. This will produce e.g. 1.0.1.

(Please Correct me if I am wrong, or if this does not work long-term.)

Answer 3

If you're just looking to bump the major, minor or revision version number, using counter operator in a variable is a simple and elegant approach. It will automatically add one to the current value.

Here's what I use:

variables:
  major: '1'
  minor: '0'
  revision: $[counter(variables['minor'], 1)] #this will get reset when minor gets bumped. The number after Counter is the seed number (in my case, I started at 1).
  app_version: '$(major).$(minor).$(revision)'

If you would like to see a real-world 4-job pipeline that uses this, I have one here https://github.com/LanceMcCarthy/DevReachCompanion/blob/master/azure-pipelines.yml

Answer 4

For me it's enough to set Build number format on Options tab to

$(date:yyyy).$(date:MMdd)$(rev:.r) 

and add next build argument:

/p:Version=1.$(Build.BuildNumber) /p:AssemblyVersion=1.$(Build.BuildNumber)

In this case we manage major version manually, but minor version and build number will be set automatically. Easy to understand what version you have deployed.