Teamcity plugin issue

I’m running into a problem where triggering a deployment via Teamcity fails at the finding release stage. From what I understand from the documentation, both Create and Deploy build steps provide you with the ability to create a release and then deploy it to a specific environment. However, I’m running into an issue similar to this one :

I have attached a copy of the build log for the error I’m getting. It seems that if you delete a release in Octopus deploy, and then run the Deploy step again in TeamCity for the same version number, instead of creating a new release, it only tries to find the release and then fails with the error message shown in the attachment.

Hi,

Thanks for getting in touch. Are you re-creating the deleted release on your deployment process? Could you send us a full build log so we can get a better glimpse at what might be going on?

Thanks!

Dalmiro

Hi Dalmiro,

Essentially yes, I am re-creating the deleted release.
At the moment I’m working on setting up a CI environment and was testing my steps for triggering deployment automatically. To prevent myself from having to keep checking in changes to trigger the builds for testing, I’m just running the build in TeamCity. I have it set up so that the Octopus release uses the Version number from TeamCity to identify it.
Initially I had the deployment using the “Create Release” step, however I ran into the issue that if a build fails for some other error that isn’t code related, I can’t re-run the build again as it will fail because the “Create” makes a release before attempting to deploy, and because a release may already exist it will fail. I then decided that switching to the “Deploy” step instead might be the solution and to test it fully I decided to delete the release already created in Octopus and run it again. This is the point at which I get the error I linked above.

I have attached the full build log.

MapServices_Continuous_3958.log.zip (4 KB)

Hi Chris,

Only the Create Release step can create releases and deploy them at the same time. Deploy Release con only deploy previously created releases.

Those 2 TeamCity steps are basically wrappers of our cmd line utility Octo.exe. If re-deploying a release is something that’s gonna happen often and you need to support it, you could ditch the “Create Release” and “Deploy Release” steps and instead have 1 Powershell step that would conditionally create a release if it doesn’t exist, and then deploy it.

You can use the Octopus REST API to check if the release exists already. I can give you a hand writing that script if you need help.

Thanks!

Dalmiro

Thanks for clearing that up Dalmiro.
I think it was the wording of the help text for parameter in the “Deploy step” (see attached image) that was causing the confusion. I assumed that because the text asks you to enter a project to create a release for, that it was capable of creating a release as well.

TC_Plugin_text.JPG

I haven’t tried this myself, but have you seen that you can pass --ignoreexisting argument to octo.exe when creating the release, so that if it exists I assume it proceeds with the deployment of the existing release and doesn’t blow up. Would this help you? You can just change your team city step back to an Octopus Create Release step, then plonk that --ignoreexisting paramater in the additional paramaters box?

I tested your suggestion Darrell, but it appears to skip the deployment part of the “Create Release” step as well.
The error condition that I was trying to cover isn’t expected to be that frequent. Once I get the Automated stuff up and running, I should very rarely be re-creating a release with the same version number.

Hi Chris,

You are correct, the --ignoreexisting parameter will also skip the deployment if the release exists. Like you said, once you have this process automated, you’ll most likely create a new release with every build instead of re-creating/re-using one.

RE the help text, you are correct once again. I’ve opened an issue to get that fixed up.

Dalmiro

If --ignoreexisting doesn’t deploy you can do this I guess:

Step 1: Create Release --ignoreexisting, don’t deploy
Step 2: Depoy Release

This means if the release exists, step 1 will still succeed and step 2 will deploy it?
if the release doesn’t exist, step 1 will create it and step 2 will deploy it.

Correct! good thing about flexible tools is that there are many ways to achieve your goals. You went ahead of me this time, kudos for that!