I am having an issue with a lifecycle.
Lifecycle with 2 phases; DEV -> PROD
Successfully deploying to DEV unlocks the PROMOTE TO PROD option
If I then re-deploy to DEV, but cancel the deployment while in progress, it locks out the option to deploy to PROD.
I would expect that, given I have had a successful deployment to DEV, even if it is not the most recent deployment, that promotion would be an option.
Is this the intended behavior? Is there a workaround beyond re-deploying? We have one project that has a multi-hour deployment that went successfully, and then it was triggered again, so I canceled it. I now cannot deploy to the next phase without deploying again to the first phase.
EDIT: This is on Octopus 3.4.11. If this is fixed on a newer version, I apologize as I didn’t see that ticket, and I can upgrade.
Thanks for getting in touch! This is intended behavior, as a promotion requires a successful deployment, or a deployment to its own environment. As the last deployment to dev is then not successful prod is again blocked. There are a couple of options you have here to work around.
The first is to create a custom Lifecycle where both Dev and PROD are in the same phase so Octopus thinks they are not locked. This is not very good practice though.
The other option is to delete the release which should free up the option to promote.
Let me know if that helps.
Sorry, I may not have made the process clear. It’s not a new release being created that is causing the issue, I would assume that would be locked, as each release requires a successful deployment to be promoted. This is a single release which HAS had a successful deployment in the past. That release was then re-deployed accidentally and canceled, which disabled the promotion. Given that 5 minutes earlier I was able to promote the release to the next environment, this seems like it might not be intended behavior.
Release 1.0.0 Deploys to DEV
Promote to PROD is available
Release 1.0.0 Deploys to DEV - Canceled
Promote is no longer available, it must first be re-deployed to DEV
Thanks for getting back! The check that is done to see if promotion is available is based off the very last deployment and not the entire history of deployments for that release to previous environments.
I can see a case for either, like you can, where you ask ‘why isn’t any single successful deployment to the previous environment enough?’ and it’s a valid question. We are all mostly running on the idea that we don’t know what caused a cancellation or failure in the very last deployment, and thus it should be successful.
It is debatable either way, but we are picking caution.
Hope that clears things up.
Fair enough, I can see the desire to be cautious on that. Should it ever be a discussion internally, I’d like to have that be configurable.
Thanks for the help,