We have a setup with TeamCity creating packages and pushing them to the internal NuGet repo of Octopus. We then use ARC to auto-deploy the package to our DEV environment. This is working fine, until… we get to a certain revision number.
To be clear we control the assembly version ourselves though the AsemblyInfo,cs file. We don’t use any wildcards. So we start from version 1.0.0.0. Changing the version number to 1.0.0.1, commit, push, then TeamCity creates a new packages (with that version number) and publishes it to Octopus’ internal NuGet repo. Octopus then auto-deploys the package for us to our DEV-environment. Any subsequent change of the version number (1.0.0.2, 1.0.0.3, etc.) leads to a new package with the appropriate version number being pushed to Octopus and to our DEV-environment. All fine so far.
Until we get to version number 1.0.0.29. All of a sudden Octopus no longer publishes the package to our DEV-environment. Huh?
See the attached image showing the logs for clarification of the issue.
Looking through the code for release auto creation it looks for the latest release for the project, could it be that there is a release that has been created that is using a higher version than the package being pushed?
I’ve tested the scenario you outlined in your inital comment and I can’t replicate your issue, so I’m slightly at a loss here.
The screenshot clearly illustrates there isn’t a newer version of the package in octopus’s repo. I can just bump the version number’s revision number to replicate the issue again and again. Until I change it to 1.0.1.0 octopus won’t publish it and return the same reason in the logs.
Maybe the issue is in how version numbers are compared by octopus?
This is the process we go through when ARC kicks in:
Grab the latest release for the project/channel combination
Get the package selected for the step in the latest release that is used in ARC
Compare the new package version with the latest package version, if the new version is deemed to be less than or equal to the version in the latest release don’t create a new release, see code below:
var newVersion = new SemanticVersion("1.0.0.29");
var latestVersion = new SemanticVersion("1.0.0.28");
if (newVersion <= latestVersion)
{
Console.WriteLine("No release created for project '{0}' when package {1} version {2} was pushed. Package version is not the greatest. Automatic Release Creation is only applied for the greatest package version.");
}
We compare the versions as Semantic Versions which, in all the testing I’ve done, would equate the above example as the new version being greater than the latest version deployed. I’ve done all the testing using the codebase for 3.3.22 so I’m confused as to why it would work for me but not for you…
What the log doesn’t show is the latest version number of the package against which the new package’ version number was compared. It would be very helpful to debug this issue, if you could add that to the logs somehow.
