Botched integration with TeamCity causing wrong package to be deployed


I am using TeamCity as a build server, to build and deploy a C# application, utilizing Cake and Octopus.

I was having issues getting the build to be pushed correctly to the staging/dev environments. Upon analysis, I verified the following:

  • After incrementing the version of my application from 2.0.* to 2.1.*, I did not reset the TeamCity version counter
  • This led to a 2.1.755 package being generated and deployed, while the previous version was 2.0.754.
  • I noticed this, and reset the counter in TeamCity, so I could get 2.1.1, 2.1.2… following a semantic versioning-ish logic.
  • Upon doing this, no further builds were correctly deployed to my servers. The version number displayed was wrong and the newly-added application logic was missing.

After a few hours, I looked at the Cake logs again and saw something weird: Octopus was registering the new releases correctly (e.g. 2.1.14), but it was sending always the same package.

I attached a log file demonstrating the issue (octopuslog.txt), and an excerpt of our Cake build script (cakeexcerpt.txt) that handles the Octopus logic. I can provide more information as necessary.

My feeling is that the 2.1.775.nupkg existing physically in octopus’ folders meant that it was sorting by name - this is just a guess, however.

cakeexcerpt.txt (1 KB)

octopuslog.txt (5 KB)

On further evaluation, I realized my Cake script was not explicitly stating the package version. I just did:

	 Packages = new Dictionary<string, string>
                     { "Omnia", semVersion.ToString() }

In the cake OctoCreateRelease method, and now it’s respecting the package version sent.

Still, would it not make sense for the default behaviour to look for the most recent version instead of the semantically superior one?


Thanks for reaching out! As you discovered already, if you don’t declare an explicit package version using the packages parameter, Octopus will always pick the latest one based on package Version.

While I understand why it would make sense to you to use the date, instead of the version, we don’t consider that a good practice and we don’t follow that logic anywhere in our product.

Best regards,