I saw, by my opinion , great feature that we can enable “guided failure mode” (enabled on the level of the environment or project) and then after we have some Failed Process Step - we can decide manually if we want for example to RETRY the deployment, but from that step which failed during the deployment process or we can CANCEL the deployment and then to create a new release for deployment.
It really seems like a great option - and I was wondering - why this option is not set by default to be included for every environment or project? I don’t mean it takes too much effort to enable this manually, not in that sense, but I was just wondering from the perspective - why shouldn’t we use this feature always?
I cannot think of the reason, why we would really prefer to see something in the “failed” status and not in this “hold” status?
So please, in that sense - can you state some downsides if we use this option always?
For example: my 3rd step in the process deploys something on the target which is not available currently - in order to correct this - I will make the target available - if step failed - it means that I will have to redeploy step No.1 and step No.2 again. If Guided Failure Mode is turned on I will continue from the step No.3 which is of course more preferable.
Does this feature can have some downsides? And can it be invoked from the REST API to continue the release from the step at which deployment was stopped? Can this “retry” be invoked using the REST API? I couldn’t find with swaggerui.
Thanks for getting in touch! Great to hear the guided failure mode feature is so helpful for you! This is a great question, and I can think of a couple different factors contributing to the reason why it’s not enabled everywhere by default.
Since failed deployments via guided failure mode require users to manually fail/retry/ignore, we don’t want to end up in positions where there might be many unresolved failures awaiting guidance from users.
You can enable this per environment (though it’s disabled by default when creating a new environment). It’s most common to enable guided failure only in Production environments, so any failures on deployments to the non-critical environments just fail without the overhead of users having to go in and allow it to fail.
One more thing to note is that we generally consciously avoid making any changes to current default behavior as we don’t want to affect any possible users who were relying on how things like this work.
can it be invoked from the REST API
It sure can, and I’ve found the following link in our sample API script repository that looks like it does exactly this. Note that this script is mentioning Manual Interventions, though guided failures are also considered an Interruption.
I hope this answers your questions! Let me know if we can help with anything else moving forward.
Thanks for following up, and you’re very welcome! Thanks for your kind words as well.
I had a bit of a closer look at this sample script, and I think the only thing in it needing to be modified for the case of guided failures is to pass Guidance = "Retry" (instead of Result = "Retry"). Sorry for that piece of confusion.
The options for Guidance are Fail, Retry, Exclude (to exclude the machine the step failed on), and Ignore (which will cause the step to succeed, but with warnings).
I hope that helps! Let me know if you have any questions or concerns moving forward.
