This is causing issues trying to auto-create new releases in deployment step templates. The deployments are failing because it is trying to create a release that already exists. What are we doing wrong here?
Looking at your issue, we have come across this one before and we have a Github issue open for it. Unfortunately we don’t have a definitive fix date for this one as of yet but I will let the team know another customer has had the issue.
In the meantime we do have a workaround from one of our engineers which I hope will help you get past the issue.
The idea is to add a couple of variables to the Project to correct the release version as the release is created.
If you create the following two vars in your Project:
CurrentDay and set the value to #{Octopus.Date.Day | Replace "^0" }
NextRevision and set the value to #{Octopus.Date.Year}.#{Octopus.Date.Month}.#{CurrentDay}.#{if CurrentDay==Octopus.Version.LastPatch}#{Octopus.Version.NextRevision}#{else}0#{/if}
Then under Release Versioning, set the Version Template to #{NextRevision}
What this does is initially make sure the date doesn’t take into the account the leading Zero on the day and then it formats the version while incrementing the version correctly.
You can tweak this to your preference as needed.
If you need further clarification on this let us know and we can help out.
Thanks for the followup! This workaround does work for us. So based on the logic, this issue only exists for days 1-9 of the month? After that, there’s no leading zero.
Hi Shane
Glad to see that worked for you. And yes its the days 1-9 that cause the problem with the leading zero.
Seems we hit two bugs on that issue and they should both be addressed by the GH issue we posted.
Keep an eye on that issue as it tends to get higher priority once more customers are affected.
