Frontend: Retry failed or canceled jobs in the downstream pipelines from the trigger job

Release notes

Problem to solve

In this epic we're making it possible to retry the trigger jobs and downstream pipelines (DSPs). We're adding a retry button to the DSPs in the pipeline graph to make it easy to retry multiple DSPs without having to go into their individual pages.

Users want an easy way to retry a trigger job when they need to re-create a downstream pipeline. Currently it's not possible without re-running the entire parent pipeline.

We're considering adding a retry action to the trigger jobs in the pipeline graph. We should also consider all other places where the trigger jobs show up in the UI.

Intended users

User experience goal

When there's a problem with my downstream pipeline that is due to some upstream problem, in some cases I want to re-create a downstream pipeline after fixing the problem upstream.

UX definition of done ⏳

Learn more about how and why we use UX Definition of Done.

Click to expand

Problem Validation Phase

Problem is well understood and has been validated
JTBD is well understood and has been validated
[-] PM has communicated the opportunity canvas to stable counterparts and group stakeholders, including the Product Designer and Product Design Manager

Design Phase

Solution Validation Phase

Validate the solution to increase confidence in the proposed solution
Document the solution validation learnings
Product Designer has communicated the solution validation learnings to stable counterparts and group stakeholders, including the Product Design Manager
Update the MVC proposal with relevant insights from the solution validation
- Discuss the technical implications with Engineering
- Update issue/epic description to contain or link to the findings

WIP Proposal

Currently the trigger jobs show up in several places in the UI:

Pipelines list page (mini pipeline graph)
Pipeline graph in the pipeline page (main pipeline graph)
Jobs tab on the pipeline page (jobs list)
Pipeline editor page (mini pipeline graph)
Commit page (mini pipeline graph)
Merge request page widget (mini pipeline graph)
Merge request pipelines tab (mini pipeline graph)

As an MVC we can add the "retry" button only to the main pipeline graph. That's where users can see which trigger jobs triggered which DSPs and provides the most context for troubleshooting DSP problems. We can further validate the addition of the retry action in the mini pipeline graph and the Jobs tab on the pipeline page.

Add a "retry" action to the trigger jobs in the pipeline graph

Add a retry button to the trigger jobs in the pipeline graph
The retry button should show up on the trigger job regardless of whether the job was successful or failed

Pattern	Prototype
Confirmation popover

Retrying trigger jobs has additional implications compared to the usual jobs, it re-creates the whole DSP pipeline. We will add a confirmation message for the trigger retry which can be permanently dismissed to ensure users are aware of what a trigger retry does. Otherwise users may be unaware that a trigger retry retries a DSP and waste a lot of CI minutes.
When user confirms the "retry" action, it re-creates the DSP. The retry button becomes a “cancel” button just like when retrying other jobs. Clicking cancel will cancel the operation and bring the job and the DSP to its previous state. The trigger job status shows running until the DSP has been re-created (or in case of a failure to re-create the pipeline, until we have information about a failure). This helps indicate that the process of re-creating a DSP is in progress.
The DSP shows a skeleton loader while we’re waiting for new data to come in (the DSP status and the new pipeline ID). The retry button is disabled in that state.
Once the DSP was triggered successfully the job shows its success state.
The trigger job link is updated to the new DSP pipeline.
As soon as we have the new DSP data we show te DSP running status and new ID. The “cancel” button shows up to make it possible to cancel the DSP run (matching the actions on the DSP page, cancel shows up when running, retry shows up when the DSP succeeded or failed).

👉 Figma Specs

👉 Designs discussion

Open questions

We need to decide what happens to the old DSPs when a DSP is re-created. More context in this thread.

Proposal to be validated:

We should validate this in solution validation research with GitLab users, but my proposal would be:

Do not delete the old DSPs
In the pipeline graph and the mini pipeline graph update the DSP card to show the latest DSP and the trigger job to show the latest trigger. For example, when you retry a regular build job in the pipeline graph, we update the job pill to show the latest job, but the old job isn't deleted and is still accessible from the Jobs page. Same logic can apply to the DSPs in the pipeline graph.
The old DSPs can be accessible from the pipelines page which is a historical list of all pipelines

Permissions and Security

Documentation

Availability & Testing

Available Tier

Feature Usage Metrics

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited Jan 08, 2023 by Dov Hershkovitch