GitVersion: Multiple release candidates rejected by Octopus Deploy over Nuget package version

1
votes

I'm using GitVersion to do semantic versioning of a .net product I'm building. During the work on a specific version I typically deploy several release candidates to the "dev" and "staging" environments.

When I try to deploy via Octopus Deploy it turns out that all release candidates share the same Nuget package version. So Octopus plays nice with the first release candidate but refuses to accept the following RCs.

What is the best way to make the Nuget package version reflect the difference between release candidates so that Octopus accepts them to its Nuget store?

Additional details:

  • I am employing GitHub Flow so only master and feature branches and deployments are always from master.
  • My build tool is TeamCity.
2
.netnugetoctopus-deploysemantic-versioninggitversion

2 Answers

1
votes

Probably your best bet, based on your description, would be to switch to using Continuous Deployment mode.

This is documented here:

http://gitversion.readthedocs.io/en/latest/more-info/incrementing-per-commit/

This will basically switch GitVersion into a mode that creates a new, unique version number, for each commit in the repository. You can then tag at specific points to order to move the version number forward. This same technique is used on the GitVersion GitHub repository itself.

This configuration can be applied on specific branches, if required.

0
votes

I don't know how and where you are building your projects. But you should name your package versioning like the following options.The biggest version numbered nuget pakage will be the latest Octopus Release. If you are packaging with different code repository branches, you should fail if the version numbers are the same. You should add branch names "1.0.0.0-dev" , "1.0.0.0-master" "1.0.0.0-hotfix" at the end of the version number.

for TFS build template(build number format) $(Date:yy.MMdd.HH.mm)

for TFS nugetter build template(Version or Version seed file path) 0.0.J.B-Hotfix

for Jenkins version number plugin ${BUILD_YEAR}.${BUILD_MONTH}.${BUILD_DAY}.${BUILDS_TODAY}