Replacing existing releases with Octo.exe

Legacy Execution
1

We keep running into issues with our TeamCity build process when it comes to creating releases, specifically around when a release is created but then fails. In TeamCity, we have build steps to build our proejcts, then another build step to package that project for Octo and deploy it. But we have for several years run into the situation where it will create the release in Octo, but something will go wrong () and then you can’t re-run the job because the package number is tied to the revision number (SVN) so because there’s no change, it sees a release with the same values already exist and fails. The solution we’ve been working with now for several years is to either (a) check in a whitespace change so that the revision/package number increases by one, or (b) go into Octo and delete all of the releases that were created (another solution is to just add something like .1 to every release name as well).

There’s a parameter for --ignoreexisting but why is there not one for --replaceexisting where it deletes the release and creates a new one? It’s something we deal with several times a month and would be greatly appreciated if it were added!

Thanks and let me know if you have any questions.

2

Hi David,

Thanks for getting in touch! When designing Octopus, we elected to follow a set of continuous integration best practices. A key part of seamless integration between Octopus and TeamCity is to ensure that your build numbers are unique. That way, it will be easy to rebuild/deploy over and over without issue. The most common ways to handle this in TeamCity is to use the build number as the SemVer patch number or append it otherwise in a SemVer compliant way. (SemVer.org)

Unfortunately, without doing this, you are required to manually create a new release with a new version, when a current release fails to be created in this scenario. While removing the release is a valid workaround for this, we do not recommend it. Octopus is designed to keep a record of everything that was released/deployed. Enabling the ability to replaceexisting releases, be it a failed release, or a successful one, could open the door for auditing issues and other problems down the track.

Sadly, I cannot see this as something we will be likely to add to Octopus.

Best regards,
Daniel