We are using teamcity to generate packages and create releases for them, I am attempting to decouple the TC version numbers from the Octopus release number, and it is producing this error when I try to generate a release without a specific number attached:
Release ‘1.0.0.30-dev’ already exists for this project. Please use a different version, or look at using a mask to auto-increment the number.
Is there any documentation anywhere relating to the “mask” item mentioned above?
We are sometimes running into needing to create another release of an application with the same version because something other than our application itself is changing. Potentially tweaking a DB script or something. We are using TeamCity and cannot find a way (without maybe using powershell remoting from our TeamCity server to our Octopus Server) to delete a previously made release and recreate it. The create-release TeamCity build runner fails with a previously created release. Any thought?
Using a tag on the release number can help with these, e.g. 1.2.3-update1 or similar. Is that an option? Using different release numbers in Octopus when any content changes, even if it isn’t part of the code, is a recommended practice.
We are having the same issue as Phil. It would be pretty helpful to have another command line parameter we could pass to octo.exe from TeamCity that would tell octo to recreate the release if it already exists. Or another build runner in TeamCity allowing us to delete releases by project and version would work as well.
The ignoreexisting flag doesn’t really do what I would expect it to. I just tried using it, and while the TeamCity build doesn’t fail, no new release is created in Octopus. I would expect the existing release in Octopus to be ignored and a new one created to overwrite it.
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 1.1.2.5. The second time the job runs, it will try to create 1.1.2.5 again. The strange thing is that Octopus doesn’t even have a 1.1.2.1.
–ignoreExisting is ambiguous, because I don’t know ignoreExisting means creating again to overwrite existing, or just do nothing.
–overwriteExisting is better.