Can't deploy release to a tenant if there's a failure in another tenant

Hi,
I deployed a release to our RC environment in 3 different tenants. The deployment failed for one of the tenants. Now I would like to deploy the release to the next environment in the lifecycle (QA) for the tenants where the RC deployment was successful but the QA environment is greyed out for all the tenants. Is this the expected behaviour? I thought the tenants where independent in terms of lifecycle.

This is how it looks when I select the release

Hi Gabriele,

Thank you for getting in touch! I’m very sorry to see you’re getting hit by this unexpected behavior. I’ve been able to reproduce this exactly as you have (thank you for bringing this to our attention, and for the clear details!), and it certainly looks like a bug to me. I’ve raised this internally with the devs, and I’ll make sure to reach out with any and all updates.

In my test, I’ve found that this happens when the most recent deployment of the release to any tenant failed, it prevents promotions of the same release for other tenants, even though previous deployments of this release were successful to those other tenants. If the most recent deployment of this release was successful, this allows promotion for the other tenants.

Even in this situation as you are in currently, trying to promote the release via the CLI doesn’t work, as it’s recognizing the release as not yet in the phase, which seems incorrect. So the only workaround I can think of is to deploy this same release again to any tenant in this environment, which I’ve found then allows promotion for the other tenants.

I’ll be in touch again, but please let me know if you have any questions or concerns in the meantime.

Best regards,

Kenny

Hi Gabriele,

Quick update while the engineers start to investigate. They had a good idea for what is likely a much better workaround for the time being, which I confirmed does work. You can manually edit the state of the failed deployment to be a success, which then allows promotion for the other tenants.

I hope this helps!

Best regards,

Kenny

Hi Kenny,
we’re aware of the edit state workaround but we didn’t expect the failure in one tenant to block the other ones. Do you know if there is a way to change this behaviour and make the tenants independent?

Hi Gabriele,

Thanks for following up! Great to hear you’re aware of that workaround. I’ve been discussing this actively with the engineers. This is indeed not the intended or expected behavior, and a bug report for this has been raised here:

Unfortunately we’re not aware of any other workarounds. My sincere apologies for the confusion and inconvenience we’ve caused here. Please let me know if you have any further questions!

Best regards,

Kenny

Thanks Kenny,
I’ll keep an eye on github, hopefully is not too hard to fix.
Cheers,
Gabriele

1 Like

Hi Gabriele,

Could you let me know which version of Octopus you’re running? I reproduced this in the latest cloud version (v2023.2.4819-hotfix.4932), and we’re wondering if you’re on an earlier version so we can try to get a better idea on whether this bug is recent.

I appreciate you reporting this!

Best regards,

Kenny

Hey, we’re running 2022.3.10750

Thank you for letting me know. I’ll pass that along to help with the investigation.

Kind regards,

Kenny

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