The following has caused me quite a headache.
Nuget requires packages to start with the Version ID, followed by any identifiers, such as:
Meanwhile, Octopus requires packages to have their Version after any identifiers, such as:
This naturally causes problems when trying to use both in one pipeline. In my case, I was packaging a package with NuGet and then trying to push it with Octopus, which caused Octopus to start using the wrong packages as soon as multiple different packages were in the system.
In my case, I had packages with the following NuGet-conform identifiers:
And while the develop builds would correctly deploy the develop packages, the alpha builds would incorrectly deploy the develop packages as well, even though a newer alpha package was available in the package feed.
I eventually managed to fix this by providing the following parameter to our TeamCity configuration, with
%build.number% being the variable that translates to either
0.0.0-develop.34 in this case:
I find this a bit redundant since I already specified
%build.number% in the
Release number: field in the TeamCity build step configuration, but then I guess Octopus has no way of knowing that this is the package name we intend for it to use. The curious consequence of this was that I had releases called “0.0.0-alpha.379” that deployed package “0.0.0-develop.34”.
In fact, the first thing I checked upon running into this issue was if the TeamCity “Octopus: Create Release” build step had a field for specifying the package ID, which would have been the first thing I would have tried. Since it didn’t, it took me some time to come to the above mentioned solution. I don’t know if this is the right place to request this, but maybe it would be a good idea to include such a field in the TeamCity Octopus plugin? After all, one of the things that has always puzzled me thus far is "How does Octopus know which package I want to deploy if there is no field to specify it?