Hi,
I’ve faced with some inappropriate behaviour of Octopus when delaing with TFS.
TFS2017.1 feed has nuget packages with release version like 2.1.0.0 and filename ending as 2.1.0.pkg. It’s some particular nuget.exe/TFS bug or feature, which doesn’t matter unless we work with Octopus.
Octopus (3.13.3), having been manually pointed to 2.1.0.0 at the release creation, correctly downloads the required version.
However, in a default scenario, it cannot cope with a new release. Without a human manipulation, at creating the release, it detects the release version as 2.1.0, apparently trying to read the versions from the filenames. After that, at the deployment, Octopus cannot read the feed, trying to download non-existing release 2.1.0 and stopping with the error.
The same we’ve got with the opposite versioning, i.e. a release version 123.1 and corresponding filename 123.1.0
Looking forward to any solution.
Thanks, Sergey
We believe you are hitting the “NuGet zero quirks” problem as described here. Eg. “Nuget 3 started removing leading zeros and the fourth digit if it is zero.”
Regarding this part:
TFS2017.1 feed has nuget packages with release version like 2.1.0.0 and filename ending as 2.1.0.pkg
The version number and the package filenames should match. Eg. If your TFS feed is hosting a package version 2.1.0.0, Octopus will expect a package filename ending with 2.1.0.0.pkg, so that is where we would recommend focusing your efforts. Could you please let us know how you are creating your packages? Are you using OctoPack and the OctoPackPackageVersion argument as per this TFS documentation?
If the problem is related to packaging, you could try using the Octo.exe command line tool to package your NuGet-packages, so they retain their correct 2 or 4-digit filenames (or make sure you consistently only use 3-digit versioning everywhere for consistency).
How are you passing the package version number to Octopus at release creation time?
If the above doesn’t help, could you please supply some more details about your TFS build process, screenshots of the steps (and any helpful logs) so we can better understand your setup, and specifically how you tell Octopus the version number to use for your packages?
Hi Mark,
Thank you indeed for pointing the links to the issue description and possible solutions.
Yes, we actually use nuget default version in the build definition steps to generate a release due to the difference between dev and prod environments fully separated. And, according to the provided details, it is obviously the same problem I’ve described in the thread.
However, having the workaround you provide, it is still unclear for me why Octopus cannot consider such inconsistencies with versions being properly coded. I did a bit deepr research what is going on with the versioning. From TFS REST API it is found that GET packages returns JSON with Two versions like:
“normalizedVersion”:“2.1.0”,
“version”:"2.1.0.0"
It’s using nuget feed V3 with the last API version. Having a lot of automation made to use external feeds in our project, I exploit exactly the same TFS API calls for an automatic build generation via Octopus API, and point the issues while doing a manual intervention in this process.
To my mind, it’s obvious now, that Octopus still uses different methods to address the packages, which hardly can be explained by nuget drawbacks. Even though the workaround is available, I believe the problem should properly be addressed in Octopus, is not it?
Thanks for the additional information. We think we’ve found the problem.
To try a workaround, in your Octopus Deploy package step (in your deployment process), could you please change the package “Download options” to “Each Tentacle will download the package directly from the remote server”, create a new release and see if that then works as you would expect?
Tentacles use our Calamari library, which does a SemanticVersion comparison (which should see 2.1.0.0 and 2.1.0 as the same version), whereas the Octopus Server logic does a string comparison (which we believe causes the problem with version scenarios like this).
Hi Mark!
Thank you for the great tip! The download by a tentacle is perfectly working in both my situations, with ending zeroes and vice-versa. So, for a quick solution, it may be Octopus + tentacle on the same server as a deployment target .
At least, in this stage, we can afford having ports opened for tentacle service.
Nevertheless, will appreciate a permanent solution securing our further deployments.