Hi, I’m wondering if anyone else has experienced this problem (or if the Octopus staff can help).
We’ve been running Octopus deploy successfully for many months now, in tandem with TFS and Git. It is one of the best software development / devops tools I’ve ever used. I’m using automatic release creation which has been working 100% reliably - until now.
I’ve changed the versioning of my NuGet packages to include a suffix like -dev to indicate a dev build versus a release build. They used to be in the format 2015.07.15.2 and are now set to the format 2015.0715.17-dev2. The package name is identical to before, but now automatic release creation has stopped working.
The packages show up with the new version numbers in Octopus’ packages feed, but they do not trigger a release creation. Strangely, even though the NuGet packages are named the same as before, I also now see duplicates listed in the main packages list. However when I click into one, all the different versions are listed together as if they are from one package (which is what I would expect).
Is Octopus seeing these newly versioned packages as completely new packages, and therefore is not linking them to the automatic release creation in my project?
Thank-you for the kind words. I’m glad to hear you’re enjoying Octopus Deploy. Now let’s see if we can get your issue resolved.
Pre-release packages can trigger automatic-release-creation. I have just tested and confirmed this.
A release will only be created if the pushed package is the latest version. From your screen-shot, you seem to have changed version number formats. Some packages seem to have been pushed using
{Year}.{Month}.{Day}.{Build}
while the pre-release builds seemed to switch to
{Year}.{Month}{Day}.{Build}
and there is also a
{Year}.{Month}.{Day}-dev-{Build}
My suspicion is these changes have got Octopus Deploy confused as to which is the latest version.
I recommend deleting all versions of the package, and re-uploading the latest version of the package. And ensure your pre-release versions use the same version format as your stable versions.
Thanks for your reply and apologies for the delay in posting this update. I did actually try deleting all versions of all packages involved, and still had the same issue.
To fix our process I have moved to creating the release via the REST API via a Powershell script (which is run by our build server). I never did work out why the automatic release creation stopped working.
We’re back up and running anyway, so thanks for your help.
We’re seeing the same problem I believe. I’ve made sure that the version numbers are in order, and the latest is the highest. We don’t have any stable versions yet, so that eliminates one area of concern.
Let me know what additional information would be needed, maybe some information from a different angle will help narrow it down.
Thanks for reaching out. Could you please share us a screenshot of your deployment process? make sure the whole screen with all the steps can be seen. Also, which version of Octopus are you running?
Hi Dalmiro,
We’re updating the pre-release tag on each build, so the next one would be 2.1.0-zalpha0093. I did the step from 2.0xxx to 2.1xxx to see if that helped, and it didn’t. I didn’t send the software version last time sorry, we’re using the latest publicly available one. This is a Poc for my part of the organization to see if Octopus can help us improve our deployments to Azure.
Could you please share us your Octopus Server Logs so we cans see if any warning were generated when trying to automatically create a release? If possible, push a package that should be triggering an automatic release right before you get the logs, just to make sure an entry related to this can be found right at the bottom.
Feel free to attach the logs here or to send them to support@Octopus.com if you want to keep them private.
Thanks Dalmiro,
For anyone else that this may help, the ordering of the trigger for automatic release creation was not correct. The script I was using to push the packages was pushing them up in a different order than the process steps. However after correcting to the correct process step that was pushed last, there is still an issue where it can’t find the correct package. The solution given previously and again by support here is to use octo.exe to create the release. Trying to use the auto trigger with multiple packages pushed up nearly simultaneously wasn’t quite working for us.
