Before upgrading to Octopus 3.4 we had a system where we would create releases from specific branches. Each branch (following the GitFlow pattern) would create a specific deploy:
This pattern allows us to deploy to specific environment from pushing to Git. For the master branch (Production deploy) we would create a new environment called pre-production where these builds were automatically pushed to from TeamCity. That step (Pre-Production) would basically do nothing except create a release for us to easily promote to production (almost always scheduled during the night).
I suspect that with this change (https://github.com/OctopusDeploy/Issues/issues/2415) we can’t do that any longer, since TeamCity builds stop at the following error while deploying to the empty Pre-Production step:
There are no steps to run when deploying releases of [PROJECT NAME] in the Default channel to the Pre-Production environment. This can happen if your deployment process is empty, or review the filters applied to the steps in your deployment process.
Now, I have to create a ‘do nothing’ step in my process to accommodate this new check.
Is there a way to relax this check? Maybe disable it using an argument on octo.exe?
Thanks for reaching out. Quote from your initial message:
That step (Pre-Production) would basically do nothing except create a release for us to easily promote to production (almost always scheduled during the night).
Why do you need this Pre-Production environment that does nothing to later on promote to Production? you could have Channel that uses a lifecycle that only has the Production environment on it, allowing you to deploy straight to it.
That said, you’ll always need to have a step in your deployment process to trigger a deployment. So If you decide to stick with this “Pre-Production” environment model, you’ll need to add a “do nothing” step on it. No way to relax this I’m afraid.
The reason we need the Pre-Production environment is because we don’t want to directly deploy to production once we pushed to the master branch.
TeamCity creates a release in the pre-production environment allowing us to easily promote that release to production, but having it run at night.
I have the ‘do nothing’ step in place now, but I’m sure other people would like to be using the system like this.
A better way would be to have a step in the deployment that would pause the deployment process, and wait for either to select a time to resume or directly resume. I don’t think this is possible using the manual intervention step.
The way we’d recommend you to do this would be to have a channel that uses a lifecycle that only has the environment Production in it. Then from your TeamCity build config, once you push to master, only create the release in this branch, but don’t deploy it. That way you’ll have your release ready to be deployed straight to Production at night.
This issue has been closed due to inactivity. If you encounter the same or a similar issue and require help, please open a new discussion (if we asked for logs or extra details in this thread, consider including them in the new thread). If you are the creator of this thread and believe it should not be closed let us know via our support email.