CODEWITHSUNDEEP
tfscontinuous-integrationnugetproget
GetFuzzy
GetFuzzy

Reputation: 2158

Nuget Package Versioning & promoting from CI to Production Nuget feeds

Technologies:

Proget – Nuget Package management server

TFS – On premise 2017 Update 1

Issue: When re-releasing a build from TFS release, to re-package a CI Nuget package that has already gone to my Proget development feed, there does not appear to be a way to get automatic Semantic versioning. The help dialog that appears in regards to setting the version within the Nuget packager setup is as follows.

Use Date and Time If you choose 'Use the date and time', this will generate a SemVer-compliant version formatted as X.Y.Z-ci-datetime where you choose X, Y, and Z.

Use an Environment Variable If you choose 'Use an environment variable', you must select an environment variable and ensure it contains the version number you want to use.

Use the Build Number If you choose 'Use the build number', this will use the build number to version you package. Note: Under General set the build format to be '$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)

enter image description here

I’d like to be able to re-release a Nuget package that has gone from my CI build in TFS to my Proget development feed, over into my production Proget feed. Microsoft has a great article on Versioning NuGet packages in a continuous delivery world. In that article they elude to the fact that they are doing something similar, but they aren’t providing any real direction for how it was accomplished.

Question:

How would you configure the Nuget packager so that upon creating the package you would input a build variable? Or is there a way that you could set the major version and just have the minor increment each time? How are others handling the promotion of packages from development to production?

Have tried the following:

Tried $(Version) as a build & release variable, and it doesn’t seem to work. The package gets tagged with the date. Also, this only seems to be really functional in the Build portion of TFS where the modal window contains a spot to modify this value.

Tried using the date & time method, and it sticks CI into the build number. This is almost exactly what we want minus the CI definition. Because it automatically inserts CI, this is not suitable for production.

Turned it off and it pulls the version from the Nuspec, but then this would assume that in your CI build you are always upping the version number to one more than current after you have pushed your last release version. This is because the nuspec is in the build files that you are re-releasing through the TFS release chain. Confusing to say the least.

Use the build number set to $(BuildDefinitionName)$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r) What I’d like here is $(Major).$(Minor).$(Patch). Trying $(Version)$ with a version of 1.0.0 gets you a file named with that has 2017.11.3.1 as the output, seemingly ignoring the $(Version) variable.

Upvotes: 4

Views: 2066

Answers (1)

PatrickLu-MSFT
PatrickLu-MSFT

Reputation: 51093

Not sure if I totally got your point, seems you would like to create a semantically versioned nupkg after ci process on TFS.

Usually the nupkg should be as shown MSVersioningSample: 1.0.8-ci-20171106-156033.nupkg

However you would like to rename nupgk and republish it to nuget server as the release version simply MSVersioningSample: 1.0.8.nupkg The same as $(Major).$(Minor).$(Patch).

You need to edit NuGetPackager.ps1 in the build agent, change the $VersionRegex value, details you could have a look at the answer in this question: How do I get TFS 2015 to parse 3 digit versioning for NuGet packaging

Also give a try with some 3-rd party extension to handle with Semantic Versioning in TFS build, release task, nuget package, a sample for your reference: Semantic Versioning Build and Release Tasks

Besides just a note: Semantic Versioning 2.0.0 is only supports with NuGet 4.3.0+ and Visual Studio 2017 version 15.3+.

Upvotes: 0

Related Questions