There is a project which used to have a lifecycle with environments A and B.
A release N is created and deployed to env A.
A trigger is created to auto-deploy to new targets when they become available (in any env).
Lifecycle is then changed so that env A is no longer included.
A new deployment target in env A is added.
Auto-deployment of release N to the new target starts, but fails.
I try to run it again manually (via the Try Again... button from the failed deployment), but I get this (and env A is not available on the dropdown list):
I expected the auto deployments and manual deployments to be consistent, so that either both are able to run or both are blocked. As is, I can’t see any way to retry that failed deployment.
Thanks for all the info. We are looking into it now and reproducing the issue.
Because the release N is referencing an environment that no longer exist in the lifecycle you could create a new release as a workaround. However the new release will include any updated variables.
I’ll be in touch with more information for you once we have reproduced the issue.
Hi @Jessica_Ross, if I create a new release, that environment (A) won’t be available for deployment (which is expected). However, I want to redeploy a release created when that environment was in the lifecycle and I want to redeploy to that env.
I have reproduced your issue and there does seem to be a bug here. After discussing this with 2 other developers, we agreed that the Auto-deploy shouldn’t be triggering a deployment for an Environment that’s no longer in the lifecycle the same behaviour for both auto deploy and manual deployments, where that if you couldn’t manually deploy to that environment then you shouldn’t be able to auto deploy to it.
