How to allow Octopus to repeatedly deploy packages with the same version number, I mean not manually on the release details page, but by setting it to allow successful releases even if the version number is the same.
Thanks for getting in touch! I’m not sure I understand precisely what you’re after, so my apologies if my answer isn’t straight to the heart of your question. Please let me know if that’s the case, and any elaboration on the behavior you’re wanting and what you’re experiencing will be helpful.
Are you wanting to make Octopus automatically select a single package version when you’re creating brand new releases? In this case I imagine you’re hitting the behavior where Octopus will grab the latest package version available. So if you want to keep using v1.0.0, but v2.0.0 exists in the target repo, Octopus will automatically select 2.0.0, forcing you to override it by select 1.0.0 manually when creating the release.
If this is the behavior you’re after, you could tweak the channel version rules tied to the applicable package step(s) to exclude other versions from being considered. E.g. in my example above (I want 1.0.0 to be selected but not 2.0.0), my channel’s version rules would have a version range of
[1.0.0,1.0.1) which effectively means anything between 1.0.0 → 1.0.1, excluding 1.0.1.
If you’re creating releases via the CLI or your build server plugin you can also pass the argument
--package=PackageId:Version specifying 1.0.0 there.
Let me know what you think or if I’m off the mark in any of my assumptions at all.
Thanks for your answer, however, you misunderstood what I meant.
The effect I want to achieve is that every time I submit code in Azure, even if I don’t modify the version number of the package published to Octopus, Octopus can automatically publish the package to the target server (the release version number uses the version number of the package).
For example, the version of the previous package is 126.96.36.199, and the version of the package I submitted again is also 188.8.131.52. I want Octopus to automatically and successfully deploy this package to the target server.
We would generally recommend that any changes made to a package be accompanied by a change to the version to prevent confusion with any eventual troubleshooting.
If you added the build number to the version (e.g. 184.108.40.206.2303) this would allow you to make use of Automatic Release Creation when the new package is added to Octopus. Then, the first environment in your lifecycle could be configured to auto-deploy allowing the newly pushed package to automatically deploy.
The only way I can see to do this without a change to the package version would be to use a scheduled trigger to re-deploy the latest release to your environment. However, you may need to test whether this would download the newly overwritten package or use a cached version of the original package.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.