Using a specific package version pushing from TeamCity to Octopus Deploy
We found an issue that is already mentioned on the forum, although sadly, the responses sounded like a combination of "I don't understand" and "Here's a nasty workaround".
The problem is this: Octopus will take the latest version of the package you specify for deployment and has NO mechanism to lock this down to the Octopus release number in the GUI config. This might make sense when you are deploying multiple packages as part of a deployment, but often we want to have a single package in a single deployment with the versions all matching up.
Because it has this behaviour, we had a build problem, where the packages are not pushed to the feed but Octopus doesn't care, it just keeps deploying the same, latest version package again and again. It takes human input to spot the old code and work out what was happening.
The workaround isn't terrible but in TeamCity, in the "create octopus release" step, you can pass something like this in the "Additional command line arguments" field:
--package=MyPackageName:1.0.34.2
The details of which you can inject with Octopus parameters, perhaps:
--package=%system.teamcity.buildConfName%:$build.number%
Note however that Octopus will take a long time to fail if the package is not present in the feed (it tries 5 times and waits 20 seconds in-between) = 100 seconds before your failure. Fortunately, the error message is self-explanatory when it finally gets written.
The problem is this: Octopus will take the latest version of the package you specify for deployment and has NO mechanism to lock this down to the Octopus release number in the GUI config. This might make sense when you are deploying multiple packages as part of a deployment, but often we want to have a single package in a single deployment with the versions all matching up.
Because it has this behaviour, we had a build problem, where the packages are not pushed to the feed but Octopus doesn't care, it just keeps deploying the same, latest version package again and again. It takes human input to spot the old code and work out what was happening.
The workaround isn't terrible but in TeamCity, in the "create octopus release" step, you can pass something like this in the "Additional command line arguments" field:
--package=MyPackageName:1.0.34.2
The details of which you can inject with Octopus parameters, perhaps:
--package=%system.teamcity.buildConfName%:$build.number%
Note however that Octopus will take a long time to fail if the package is not present in the feed (it tries 5 times and waits 20 seconds in-between) = 100 seconds before your failure. Fortunately, the error message is self-explanatory when it finally gets written.