While we have
allow_failure, these only work on actual step failures, not on canceled steps. In other words, if one has a “clean up” step it will not run if one manually cancels a step. Presumably, one might want a finalizer to always run to clean up external resources or perform some sort of logging action (perhaps to record metrics in an external system).
I understand that utilizing external resources may be an anti-pattern, but it’s hard to avoid when dealing with backend infrastructure, distributed systems, or scale testing. It also seems trivial to add (from a conceptual and implementation perspective) by following the existing patterns:
allow_cancel or something along those lines. (Of course, thinking about step-level vs build-level cancel operations may complicate this… I’m sure you could come up with something clean if you thought about it, though. :) )
NOTE: this likely overlaps with other topics related to cancel behavior, such as capturing the cancel status as a separate code and color (which we’re a big +1 on).