Correct support of SemVer 2.0

Saber_Karmous · 27 May 2014 12:04

i’m currently using Teamcity + Octopus + Octopack to build and deploy.

What I want is to generate a version number in the following format

1.0.0-develop.86

Unfortunately octo.exe doesn’t seem to accept that format. But it accepts 1.0.0-develop86. I see the following in the buildlog of teamcity

13:03:34]Release plan for release: 1.0.0-develop86
[13:03:34]Steps:
[13:03:34] # Name Version Source
[13:03:34] — ------------------- --------------- ------------------------------------
[13:03:34] 1 Demo.Todo website 1.0.0.86 User specified
[13:03:34]
[13:03:34]Creating release…
[13:03:34]Release 1.0.0-develop86 created successfully!
[13:03:34]##teamcity[setParameter name=‘octo.releaseNumber’ value=‘1.0.0-develop86’]
[13:03:35]Deploying Demo.Todo 1.0.0-develop86 to: Test (Guided Failure: Not Enabled)
[13:03:35]Waiting for 1 deployment(s) to complete…
[13:03:55]Deploy Demo.Todo release 1.0.0-develop86 to Test: Success
[13:03:55]Done!

Another issue is that I haven’t been able to use 1.0.0-develop.86 as a version for the nuget package that’s being generated during build.

The nuget package is published to the built Teamcity repository.

Paul_Stovell · 28 May 2014 09:19

Hi Saber,

Thanks for getting in touch! This is a limitation of NuGet - in the attached screenshot you’ll also see that NuGet Package Explorer doesn’t support this format. I know this isn’t the answer you’re looking for but unfortunately there isn’t too much we can do about it until NuGet also supports this syntax.

Paul

Saber_Karmous · 29 May 2014 19:14

Ah I see… No worries. Then I suppose I have to live with the missing last dot

Justin_Turner · 9 June 2014 15:34

Thanks for posting the question and clarifying from Octopus. This is a pretty critical feature that is missing. We’ll be able to work around of course.

johnkors · 5 November 2014 14:03

A bit off topic, but any recommendations on how to create such a pre-release package in Team City using a automatic build incrementer?

There’s a known issue using 1.0.0-develop{increasing number} as NuGet orders it alphabetically. So pretty much there are two solutions

Padding and using build number of TC: 1.0.0-develop0000086 (numbers zero-padded to 6 in length in this example)
Using timestamps: 1.0.0-develop-20141105120000

Both are hard to do in TC wihtout any plugins I find.

Damian_Maclennan · 6 November 2014 03:22

Hi John

We’ve just accepted a pull request for OctoPack which may solve your problems, take a look at this http://help.octopusdeploy.com/discussions/problems/25784

Would that help you ?

Regards

Damian

johnkors · 6 November 2014 05:54

No, that would change the package id of the nuget package, which is very much not recommended.

Paul_Stovell · 10 November 2014 00:37

Hi John,

We do this using a PowerShell step as the first step in our TeamCity build process. We leave the build number TeamCity generates, then based on the branch, we append a tag. See below for an example:

# These are project build parameters in TeamCity
$prodPrefix = "%MajorMinorVersion%"
$prePrefix = "%MajorMinorVersionPreRelease%"
$devPrefix = "%MajorMinorVersionDevelopment%"
$release = "%build.counter%"  # TC's auto-incrementing number

$branch = "%teamcity.build.vcs.branch.OctopusDeploy_GitGithubComOctopusDeployOctopusDeployGitDevelop%"
$branch = $branch.substring($branch.lastIndexOf("/")).trim("/")

write-host "branch: $branch"

if ($branch -eq "master") 
{
 write-host "This is a master build"
 $release = ($prodPrefix + "." + $release)
}
elseif ($branch -match "release-.*") 
{
 write-host "Special release build"
 $release = ($branch -replace 'release-(.*)','$1') + "." + $release
}
elseif ($branch -eq "release")
{
 write-host "This is a pre-release build"
 $release = ($prePrefix + "." + $release)
}
elseif ($branch -eq "develop")
{
 write-host "This is a vNext build"
 $release = ($devPrefix + "." + $release)
}
else 
{
 write-host "This is a feature branch build"
 $release = ($devPrefix + "." + $release + "-" + $branch.Replace("-", "").Replace("feature", ""))
}

write-host "##teamcity[buildNumber '$release']"

Paul

johnkors · 10 November 2014 12:13

Thanks Paul.

From what I can tell this script bypasses the issue by inserting the counter at the patch. I presume that you then at release build will have to match the MAJOR.MINOR.PATCH to be the same as the pre-release-version, so you re-set the counter in TC manually.

Work on a pre-release will generate the following packages
Feature-branch:
packageid.1.1.1-branchname
packageid.1.1.2-branchname
packageid.1.1.3-branchname

“Okay, we are finished with the 1.1-version, and the final package version will be 1.1.3. Update TC-variable %MajorMinorVersionPreRelease% and the TC counter so that it says 1.1.3”

Either that, or you don’t care about the matching of MAJOR.MINOR.PATCH when working on pre-release-package and decide upon what kind of release version this is at the time of generating a release-package.

I’m guessing it’s the latter?

What I would like is another setup

Feature branch for 1.1.3
packageid.1.1.3-branchname-{ zero padded counter/timestamp}
packageid.1.1.3-branchname-{ zero padded counter/timestamp}
packageid.1.1.3-branchname-{ zero padded counter/timestamp}

Release build
"Set Major.Minor.Patch to 1.1.3 and package away)

Paul_Stovell · 12 November 2014 23:35

Hi John,

Sorry if my script was misleading, I was just pasting something we had to be a starting point for you, it wasn’t intended to be exactly what you needed. Here’s a new version that might be closer to what you need:

# These are project build parameters in TeamCity
$majorMinorVersion = "%MajorMinorVersion%"
$release = "%build.counter%"  # TC's auto-incrementing number

$branch = "%teamcity.build.vcs.branch.OctopusDeploy_GitGithubComOctopusDeployOctopusDeployGitDevelop%"
$branch = $branch.substring($branch.lastIndexOf("/")).trim("/")

write-host "branch: $branch"

$release = $release.PadLeft(6, "0")

if ($branch -match "release-.*") 
{
 write-host "Special release build"
 $release = ($branch -replace 'release-(.*)','$1') + "-release-" + $release
}
else
{
 $release = ($majorMinorVersion + "-" + $branch + "-" + $release)
}

write-host "##teamcity[buildNumber '$release']"

Examples:

Assuming MajorMinorVersion is set to 1.1.3 and the TC auto incrementing counter is 15.

Branch: foo, version: 1.1.3-foo-000015
Branch: bar, version: 1.1.3-bar-000015
Branch: release, version: 1.1.3-release-000015
Branch: release-1.1.4, version: 1.1.4-release-000015 (special case)

Hopefully this is a good starting point for you to adjust to suit your needs!

Paul

Paul_Stovell · 13 November 2014 01:00

A wrote a blog post about this with more details:

Paul

Kieran_Benton · 30 July 2015 21:17

Hi guys,
Is this now fixed in Octopus Deploy 3 (and the newly released Nuget 3?) or not?

Cheers,
Kieran

Paul_Stovell · 31 July 2015 09:18

Hi Kieran,

It seems like they may have been fixed in NuGet 3.0, but Octopus is still using NuGet 2.8.3 since NuGet 3.0 was pretty recent. We’ll be testing against NuGet 3.0 and upgrading soon, and we’ll check if we can support the full SemVer 2.0.

Paul

Kieran_Benton · 31 July 2015 10:36

Thanks Paul - especially for the rapid response. Thats excellent news. The
story with GitVersion, TeamCity and Octopus Deploy is so close to being
fantastic now - with SemVer2 (assuming Nuget is supporting it fully) it
will be almost seamless.

Martin_Thwaites · 19 October 2015 16:33

Any news on this? it’s been a few months.

Damian_Brady · 20 October 2015 05:01

Hi Martin,

Unfortunately no update on this at the moment.

We’ve been working on the channels feature for 3.2. We’ll probably aim to include support for SemVer2 with a 3.2.x release, however not immediately.

Sorry it’s not better news!
Damo

Brett · 27 November 2015 15:02

I’m still struggling with this having to add a bunch of PowerShell scripts in our builds to accommodate limitations of Octo.exe.

I know the nuget command line still doesn’t support SemVer 2.0. Does octo.exe use the nuget command line under the covers? Do we have to wait until the nuget command line is updated before octo.exe can be fixed?

Our current solution is to override the teamcity version in the Create release step using a custom powershell script.

Michael_Noonan · 30 November 2015 01:35

Hi Brett,

Thanks for getting in touch. To answer your specific questions, yes, octo.exe uses the PackageBuilder from NuGet.Core to build packages, so we are constrained to NuGet 2.9 at the time of writing.

Rest assured we are feeling the same pain for our own builds, and it would be really nice if the pipeline from end-to-end supported SemVer 2.0 out of the box. We are determined to make this experience better for everyone but we need to move carefully to maintain compatibility with a lot of moving pieces.

Have a look over this GitHub Issue which should shed some light on what we’re planning to support for packaging moving forward. I’d be interested in your thoughts after you take a look.

Hope that helps!
Mike

johnkors · 2 February 2016 07:11

How about now in 3.3 w zip/tar support?

Michael_Noonan · 3 February 2016 23:53

Hi John,

Thanks for getting back in touch. By going through and introducing alternate package options, we’ve started the process of decoupling ourselves from NuGet, with the next step to move our use of NuGet.Core.SemanticVersion (which is SemVer 1.0) to something that supports SemVer 2.0.

We want to complete this work in stages since it impacts so much of the codebase. Our next priority is to ship multi-tenant deployment support. Whilst there may be room to fit SemVer 2.0 support into Octopus 3.4 as a side-project, we can’t make any promises to that end.

In the meantime we will all have to wrestle SemVer 1.0 (and the NuGet 20 character limit for SpecialVersion) to do our bidding.

Sorry if that’s not the news you wanted to hear, but I hope it helps.
Mike