I have an environment which has 2 deployment targets, a listening tentacle and an offline package drop.
I have a final process step which sends a Slack notification if a previous steps fails.
When a deployment failure occurs the tentacle target proceeds past the failed step and sends the notification.
However, when the Offline Package Drop fails the process just stops dead and does not continue on to any remaining steps.
Am I missing something or is this a limitation of the process?
This is a limitation of the Offline Package Drop targets.
Each offline-drop execution represents a deployment to a single machine.
Step types such as Slack notifications, Emails, etc, typically run once on the Octopus server, not once per machine. Offline Drop deployments do not communicate back to the Octopus Server; if they could they wouldn’t be offline
We are planning to implement a feature in the not too distant future which we are calling Remote Release Promotions. The general gist is that you would have an Octopus Server in each environment, and promote releases between your (possibly disconnected) Octopus Servers. This may be of interest to you.
Otherwise you will need to model your deployment process differently to account for the offline targets. Possibly sending the notifications manually for those.
I hope that helps, though I realise it wasn’t the answer you were hoping for.
Thanks for the reply. However I am not sure we are on the same pages. The Slack notification step (and all of the other steps) run on the Deployment Target not the Octopus Server. The Slack steps run perfectly well Offline when there are no failures.
Taking Slack out of the equation for a moment, my issue really comes down to the Offline process stopping dead on failure, regardless of what the remaining steps are.
Would you expect deployment target process steps to be run after a failure on a previous step?
I apologize, that part of my response was confusing.
To clarify:
When deploying to Offline Package Drop targets the process will stop when a step fails. This is one of the limitations of these targets. There is no ability to run steps on failure.
I believe the rest of my response is valid. It depends on why you are using an offline-drop target, but Remote Release Promotions is designed to vastly improve the capabilities in this area.
