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: https://g.octopushq.com/OctoexeTroubleshooting
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.