Yesterday we upgraded our Octopus Deploy to v.2018.4.4 from v.3.11.14. Everything seems to be running smoothly, except for one issue related to the (relatively) new “Deploy a Release” step.
For some background, we have two major projects that we use: our product deployment (called Trunk after the code branch it represents) and Proxy Config, which handles certain specific config file variants. Until now we’ve simply ran the Proxy Config project manually after the Trunk deployment completes, but with the new version we figured we’d add the new Deploy a Release step to do this for us:
This worked fine during testing, but the next time that we uploaded a new build to Trunk (by uploading a zip file via the GUI in Library -> Upload Package), it appears to associate the step with a build version that does not exist:
20180425.8.2 is the previous version of Trunk, but not Proxy Config. Creating a new Trunk release with no other changes seems to force Octopus to realize this and use the actual Proxy Config version (which is static and does not change nearly as frequently as Trunk does):
However, needing to manually create a release after each upload is kind of a drag. Is there some configuration we could perform to ensure this is taken care of automatically, or is it something that will need addressed on y’all’s end?
Releases are the glue that bind your packages together, creating a repeatable deployment strategy snapshot at a given point in time. Any time a package changes, a new release should be created. This can be automated through the CLI via:
Each of those releases (except the ones with a further .1 at the end) were created via manual zip file upload, which then triggered an automatic release based on the zip filename.
The issue is that while Trunk has frequent new releases, Proxy Config doesn’t, and the Deploy a Release step (within automatically created releases for Trunk) seems to think that Proxy Config follows Trunk’s versioning schema, which is not correct. Creating a new manual release (with absolutely nothing changed) corrects this error. It seems to me that the automatic release creation process that is ran when a new zip file is uploaded is not performing the same logic that a manual release creation is, for whatever reason.
I’d be interested to see what the team recommends in this case. We have a similar issue where scheduled triggers try to create a new release with package versions that don’t exist.
@miguelelvir and anyone else who might be following this: the issue was closed as of yesterday (it was apparently a regression) and has been included in the Octopus Deploy 2018.4.10 patch.
After loading the new version into a VM, I was able to confirm that this patch eliminates the behavior reported in this thread. Uploading a package with automatic releases associates the appropriate package version now.
Many thanks to @Pawel_Pabich and MJRichardson for getting it done!
(Sorry for the repeat ping/post; I was lead to believe that our devs had done something to accidentally eliminate the bug on our end, but it turned out to not be the case and I’ve retracted that post accordingly.)
