Convenience API / button to rerun failed promotion

[jessesuen]

Proposed Feature

A promotion might fail for an intermittent issue (e.g. in my case it was a timeout to github). A rerun of the promotion resolved it. But in order to rerun it, I had to navigate the UI, select the same freight, select the Stage, click promote, etc... It would be easier to make this one click.

Motivation

It will be common for promotions to fail for ephemeral reasons and we should make it easy to retry it.

Suggested Implementation

• When looking at a failed promotion, UI should display a rerun button
• When rerun, a new promotion would be created using the same steps/vars/freight etc.. of the failed promo.

NOTE: at first, I thought this would just be a UI feature. But then I thought we may need to do this at the API level. Reasons:

1. We may want to preserve the promotion steps of the failed promotion, in case the promotionTemplate had changed in the Stage with different steps. The logic of this would be too involved for the UI, so the API server would need to do it.
2. CLI might want to do this too
3. We might considered the ability to rerun a failed promotion, a different RBAC permission than promote. Use case: end user may not be given promote privileges since promotions are automatically created via autoPromote. But when the promotion fails for an ephemeral issue, users should be able to rerun it.

[krancour]

💯 on the idea. Also agree on adding an API endpoint for it.

We may want to preserve the promotion steps of the failed promotion, in case the promotionTemplate had changed in the Stage with different steps.

I feel iffy about this one aspect. Supposing the failure weren't for ephemeral reasons, but due to a flaw in the process, I can easily imagine a user updating the Stage's promotionTemplate and then retrying the promotion. In this case, you'd want to pick up the changes.

Supposing the failure were for ephemeral reasons and promotionTemplate had been updated for entirely unrelated reasons, I think those process changes still reflect the user's latest thinking on how best to move Freight into that Stage, and for that reason alone, perhaps should not be disregarded.

imho, we should consider retrying a failed Promotion by just copying the Stage name and Freight name to a new Promotion and letting everything play out as usual.

I'd still like to see it implemented as a new API endpoint, even if reusing the process as it was defined previously defined isn't the impetus for it. As noted, the CLI would for sure use it as well.