We using the Octopus Deploy Plugin for Jenkins. It works very well except we are trying to auto-increment the release number. For example, we have a release version that we pull from the git branch and then append an i per the Octopus suggestion. So a given build would try to create release 1.1.2.i for example.
It works the first time. However, the second time, it tries to create the same release. The first time, the plugin creates 22.214.171.124. The second time the job runs, it will try to create 126.96.36.199 again. The strange thing is that Octopus doesn’t even have a 188.8.131.52.
Any help here?
I believe I have been able to reproduce a scenario similar to how you describe based on a flaw in the auto-increment logic. I have added this as GitHub issue #1776.
It appears that the code always just uses the largest previously generated build number as the increment baseline, regardless if the same major/minor number as the provided pattern. If there is an existing higher release version present, it might also then get caught with this behavior you describe.
To temporarily get around this issue you could try bump the major/minor up to the next value (that you have not yet used) forcing Octopus Deploy to start the increment with no conflicting versions. Although this next release might be
x.x.x.5 (note the #5) you should be able to keep releasing with an increasing tag number.
Let me know if you need any clarification around this issue.
Ill let you know how the aforementioned bug progresses but hopefully this work around will allow you to keep deploying!
The fix for this has now gone out in the 3.0.11 release. Please give this a go and let me know if this solves your version problem.
Thanks for being patient!