VSTS/Azure DevOps：包上的自动增量 NuGet 包版本

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 eg 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.

Workaround 1:

 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'

Workaround 2:

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 eg 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.

Answer 5

I am using the ado pipeline and a yaml build. What I've done is utilized the pipeline variables, a counter function, and an inline powershell function to create the version number. It auto-increments and has made the entire build process nice.

Another SO Post about something similar