Under guieded failure mode in Octo 2.x, there was an option to apply to other failures in the same activity. Did this option get removed in 3.0?
Hi!
Thanks for getting in touch. You’re right, we removed that option in 3.0. When we changed the underlying architecture it became more difficult to correlate what failures were similar in order to apply the same action to them. We made the decision to leave that feature behind in preference to other features.
The good thing about this decision is that you’ll get the result you’d expect for each failure.
Perhaps you can provide some details of your specific situation and why this feature was useful to you.
Hope that helps!
Mike
We have a deployment task that sometimes requires multiple retries before it succeeds, and at the scale of our deployments, we sometimes see upwards of 20 failures. While the long term plan is to make the deployment task more resilient to failures, in the past the option to retry all failures at once has proven to be very useful.
Hi!
Thanks for getting back to me. That makes sense and I think you’re right on the money with your long-term plan to make the deployments more resilient since we have no plans to re-introduce that feature due to its complexity and the potential for confusion.
Happy Deployments!
Mike
Hi
I second the need for this feature which we really found useful and relied on. many times we need to use retry because something with some of the tentacles is not configured properly especially after the upgrade (which required the restarting the service on many of them) then going over each failure and hitting retry multiple times instead of once is pretty annoying.
shame you can’t fix this, but one other thing i notice since the upgrade with regards to guided failures:
in the past (2.6.4) if a step failed when using guided failure and then we used retry - in the deployment log it would look very clear:
the step that failed would be marked as red and the new one which is being retried would restart and displayed separately.
now the retry continues from where the previous failed in the same deployment space
this makes the retry feature (which we were relying on) even harder to use
Thanks
Nir