Ok this one has been kicking around for a while but I think we're in good shape now.
This diff changes the re-execute button into a two-part button so a single click handles the common case. If you have a selected step in the gaant view and that selection has finished running (and you are persisting artifacts), the default is to re-execute the selection only:
If you have nothing selected, the default is to re-execute the entire pipeline and it looks like this, with the (*) syntax reinforcing that you are re-running everything in the current view:
If you click the disclosure triangle, you can see the options listed out and conditionally enabled. There is a new option "From Selection", which runs everything downstream of the step(s) you have selected by creating a step*-style query, evaluating it, and sending the step keys.
When I was revisiting this diff, I talked with Yuhan and restructured the JS side of re-execution just a bit with a few goals in mind:
- In the future, we're going to be shifting the inflation of step keys / evaluation of the step query to the python side.
- The JS code presenting the options and then invoking re-execution mutations is tricky because some re-execution options cause others to be ignored or have dependencies (for example, resumeRetry causes stepKeys to be ignored, passing a stepQuery is required but is actually just used for display while stepKeys is used to scope the run, env yaml is sometimes provided explicitly but sometimes already on the Run object). Because of this, the JS functions that assemble the mutation take many optional arguments, which made it hard to think through.
To address this, I defined a new ReExecutionStyle type which makes the relevant arguments required for each case. I also created a StepSelection type which wraps a set of step keys with the step query that generated them, because we almost always pass both together these days.