Hi Support,
We are very occasionally seeing issues when creating releases from Team City where we get the following error: “Release ‘x.y.z’ already exists for this project.” In every case, we have seen where another Team City build has just created another release only seconds before the failed release. In one case, I saw the following two lines from two different Team City build projects:
(from project 1 build log in TC)
[11:57:59][Octopus Deploy] Using version number from release template: 16.11.805
(from project 2 build log in TC)
[11:58:02][Octopus Deploy] - Release ‘16.11.805’ already exists for this project
We have Octopus set to use #{Octopus.Version.LastMajor}.#{Octopus.Version.LastMinor}.#{Octopus.Version.NextPatch} as the version template for the Octopus project. We have a series of 20 or so build projects in Team City that all create releases of the same Octopus project. It only seems to happen on calls to octo.exe that are only seconds apart. Any ideas?
Hi Matt,
Thanks for getting in touch. We don’t often see situations where people create releases in Octopus from multiple sources causing this kind of contention. The release version increment code can yield the same results if called concurrently. Unfortunately it isn’t practical to provide a logical “lock” or “lease” for Release Versions because it is a two-stage process when creating a release:
- Get a
ReleaseTemplate which has the calculated version on it - this gives you a chance to manually override the Release Version if you want
- You build the Release and POST it back to the server - at this point we can’t really do anything except detect duplicates and return an error response like the one you are seeing.
I think the best way to handle this would be to work around it in TeamCity.
I would be interested to understand why multiple Build Configurations in TeamCity are all configured to create Releases for the same Project in Octopus. Commonly each “Project” in TeamCity creates releases for its logical partner “Project” in Octopus Deploy.
One idea I have is to create a Build Configuration in TeamCity to create the Octopus Releases, and share this between your different builds. That way you can configure that step in TeamCity so it will only execute one-at-a-time in sequence. (Essentially moving the “lock” to TeamCity).
Would something like that work for you?
Otherwise I only have three other recommendations for you:
- Consider whether Channels would help you in this situation. This way you would likely end up with windows of version numbers that don’t overlap. (Something like the HiLo algorithm for generating IDs)
- Use the TeamCity “Retry on Failure” build trigger to automatically retry creating the release (which will hopefully get an uncontended release number)
- Calculate the release version ahead of time instead of getting Octopus to propose one.
Hope that helps!
Mike
Thanks Michael. I your explanation makes perfect sense. I didn’t realize getting and then using the release number was a two-stage process so the possibility for duplicates is understandable.
Here’s why our TeamCity build projects and our Octopus Deploy project don’t exactly line up. Basically we have a series of micro-services (22 different web services) that are independently deployable. Let’s say for simplicity ServiceA and ServiceB. These are all different Visual Studio projects and also different build projects in TeamCity since I don’t want to unnecessarily build ServiceB and increment it’s version number just because someone checked in a change to ServiceA. However when we release them (typically monthly to production), we release them as a package – all together. So there is a single Octopus Deploy project that packages all services in a release.
Maybe what we can do is move the release creation from TeamCity to Octopus. At the moment, the last two steps our TeamCity build template that each micro-service uses push a package to Octopus for the service it just built, then creates a release so that there is always a release ready to deploy. We also have a scheduled deploy to dev of latest release once an hour – using octo.exe. Maybe what we can do have Team City continue to push the package to Octopus but not create the release. Then have the hourly scheduled task both create the release and initiate the deployment. That way we’ll only create a release once an hour instead of each time a service changes.
Aside from that, I might investigate your option 3 as well.
Thanks for your reply. It definitely explains what’s going on and know that I understand the issue I can come up with a better solution.
Final question – we do have a paid license for Octopus. License #95833-12355-11422-18249 for RMS Automotive. Is the forums still the best way to get support or are there other channels for paid licenses?
Matt
Hi Matt,
Thanks for getting back to me, and I’ll be interested to see where you end up!
Regarding support - yes this is the best way to get in touch. We actively monitor the support forums and endeavour to get a useful response to you in 24h. Nice thing is the conversations are generally public too - so it often helps others.
Hope that helps!
Mike