Inconsistent Release Promotion between Trigger in GUI and TeamCity Plugin

Octopus Deploy Version: 2019.12.7 (happened recently in), recently upgraded to 2020.2.13 (CI hasn’t broken yet)
TeamCity Plugin Version: 5.5.0

We have our lifecycle setup as follows:
CI - All Must Complete
QA - All Must Complete (Optional)
Regression - All Must Complete

Our QA Servers are on all the time for various teams to hop on and test changes. We have a scheduled trigger in Octopus which promotes the latest CI release onto this environment once a day. Of course they can manually choose to deploy releases at times suitable for them.
If CI fails for any reason, the trigger will promote (or redeploy) the LATEST SUCCESSFUL CI deployment which is what we want. We don’t want QA to be blocked because CI has broken due to a code change, which as we all know happens from time to time.

Our Regression environments are transient and are spun up by TeamCity as Cloud Build Agents when required, as such we can’t setup a scheduled promotion trigger.
We’ve configured TeamCity to promote the latest CI release onto Regression - crucially however, this behaves differently to the time trigger.
It is always grabbing the latest release, thus if CI failed the lifecycle prevents the promotion to Regression and the process fails.

Release '2020.2.0.93-86' of project 'ETRM' cannot be deployed for tenant 'ETRM Regression' to environment 'ETRM 2020.2 Regression'. This may be because a) the tenant is not connected to this environment, a) the environment does not exist or is misspelled, b) The lifecycle has not reached this phase, possibly due to previous deployment failure,  c) you don't have permission to deploy to this environment, d) the environment is not in the list of environments defined by the lifecycle, or e) it is unable to deploy to this channel.
This error is most likely occurring while executing Octo.exe as part of an automated build process. The following doc is recommended to get some tips on how to troubleshoot this:

To me this looks to be inconsistent behaviour of promoting a release - surely the time trigger promotion in the GUI should behave the same way as promotion through the TeamCity Plugin which is effectively just wrapping the Octopus API?
I’m a bit stuck otherwise how we can get the Regression to always run with the last successful release, without impacting QA by triggering every successful CI release onto there, using event triggers and having the transient environments promote from QA since we know that release should always have been successful.

Hi James,

Thanks for getting in touch! I’m sorry about this unexpected and inconvenient issue you’re hitting here. I think you’re absolutely on the money that this behavior is inconsistent, and that the behavior you’re seeing from the deployment triggered by TeamCity is what needs to be changed in order to match how the scheduled trigger correctly selects the release to deploy.

Sure enough I’ve been able to reproduce this behavior (thank you for the clear repro steps) and raised a bug report at the below link that you can track. This is a bug in the Octo CLI (which is what the TeamCity plugin uses under the hood), where the deploy-release and promote-release commands don’t seem to be smart enough to select the latest successfully deployed release.

Unfortunately for the time being I think the only option is to explicitly state the release version you want deployed.

I appreciate you bringing this to our attention. Don’t hesitate to reach out if you have any further questions or concerns going forward!

Best regards,


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.