How can I block an Octopus Deploy release from being deployed to any further environments?

If for some reason, you decide that you don’t want to allow a release to be deployed to any further environments, you can stop its progression.

To do this, go to the release page, open the extension menu, and select “Prevent Progression.”

This will block the release from being deployed.

See our documenation for more details.

You can also use the Octopus CLI to block a release from within a script.

I’m looking for a little guidance here as this option didn’t seem to solve my challenge.

What we have:
Automated deployments into dev at build time. Then we have a daily scheduled release into test that runs from an orchestration deployment project using Deploy a Release steps, and creates the release based on a basic pre-release tag. Both the orchestration project and the actual deployment projects use the same pre-release tag in their channel rules, which grabs the latest version released in dev. We also use a lifecycle dependency that requires that the deployment in dev must succeed before deploying in test.

What we notice:
Any failure to deploy successfully in dev results in a failed lifecycle dependency which halts the automated deployment in test until a human can intervene.

What we want:
Ultimately, we’d like the orchestration project to build a release based only on versions that were deployed successfully in dev. We were hoping that using Prevent Progression would stop the orchestration project from selecting bad releases during the release creation phase, but it’s appears that it respect that state. Is there any way to achieve our goal of only creating releases from successfully deployed projects in dev?

Thanks,

-Todd

1 Like

@finnian.dempsey I’m not sure that the original poster of this article is still active, so are you able to assist with this workflow I’m trying to figure out?

1 Like

Hi Todd,

Thank you for reaching out, and my apologies in the delay in getting back to you on this one!

This is a great question. However I don’t think there’s going to be any out-of-the-box functionality to control which release of a “child” project is chosen when creating a release of the orchestration project, based on whether or not the release has successfully deployed to an environment. The Deploy a Release step simply finds the latest release version to include in the release snapshot being created.

One potential approach might be to change the release of the child project (that didn’t successfully deploy) and tie the version rules on the orchestration project in a way that would effectively exclude the new release version from being chosen. For example, the following orchestration project’s channel has a version rule that only allows versions of the child project that do not include failed in the pre-release tag.

When version 2.0.0-beta fails to deploy to Dev, I update the release version to 2.0.0-failed, causing it to not match the version rules of the orchestration project, so it defaults to picking the latest release with -beta pre-release tag (in my case, 1.0.0-beta).

Release versions can be changed manually in the UI in the release itself, under the overflow menu > Edit.

You could also in theory automate the change of release version in the child projects via an API script, and set that to only run when other steps failed.

I hope this helps in some way. I imagine it’s not the most ideal answer you were hoping for! Let me know what you think, or if you have any questions at all. :slight_smile:

Best regards,

Kenny

1 Like

Thanks for that idea Kenny. That makes sense. Can my pre-release filter include multiple values to negate? I already use a negating filter used to exclude hotfix releases such as 1.0.0-hotfix. In order to follow your suggestion, I’ll need to exclude both “hotfix” and “failed” patterns.

Hi @tfbryan,

Just stepping in for Kenny while he’s offline.

You should be able to define multiple pre-release exclusions for the Channel’s Version Rule using the something like the following Pre-release tag: ^((?!hotfix)(?!failed).).+

I found this StackOverflow post explains how negating in Regex works: regex - Regular expression to match a line that doesn't contain a word - Stack Overflow

Hope that helps but feel free to reach out if it’s not quite right or you have any questions at all!

Best Regards,

1 Like