Draft: Show only latest downstream pipelines in the pipeline graphs

What does this MR do and why?

For #352124 (closed)

Retrying a trigger job means creating and running new downstream pipeline. Currently, the pipeline graph and mini pipeline graph shows all the old and current downstream pipelines. This is confusing to the user, since it communicates that the CI config triggers several downstream pipelines and doesn't differentiate between old and current downstream pipelines.

For example, they might think that retrying the whole pipeline will retry 10 downstream pipelines, when it might be that the CI config only triggers 2 downstream pipelines and the remaining 8 shown in the graphs are a result of retrying those trigger jobs several times.

This MR hides the old downstream pipelines and only shows the latest / current downstream pipelines in the graphs to make the situation more clear. This is done by filtering the downstream pipelines data by name and only showing the latest created pipeline from those with name duplicates.

No changelog since this feature is under a feature flag.

Latest commit has the relevant changes; other commits will be removed after a proper rebase (once the retry trigger job code is merged).

Note that the mini pipeline graph is used in several pages, such as:

• Pipeline Editor
• Pipelines Table
• Commit Page
• MR Widget

Screenshots or screen recordings

The following examples show a CI config that has triggered two downstream pipelines. This is how it it looks like before retrying the trigger jobs.

And these are the results after retrying both trigger jobs twice (resulting in 6 downstream pipelines created in total, including the first time the pipeline was created).

Page	Before	After
Pipeline Graph	before-pipeline_graph	after-pipeline_graph
Pipeline Editor
Pipelines Table
Commit Page
MR Widget

How to set up and validate locally

Set Up (Creating and retrying a trigger job)

1. Enable the ci_retry_downstream_pipeline feature flag. (rails c then Feature.enable(:ci_retry_downstream_pipeline))
2. Add the following content to your .gitlab-ci.yml file. This will create the trigger job triggerJob and create a downstream pipeline based on the contents of .gitlab-ci.yml in your other project.

   stages:
     - build
   
   triggerJob:
     stage: build
     trigger:
       include:
         - project: "/path/to/project" # replace with another project
           file: ".gitlab-ci.yml"

3. Wait for the pipeline to finish running.
4. Visit the pipeline and click on the triggerJob job pill. This should take you to the job page for triggerJob.
5. Click on the Retry button in the sidebar. A new trigger job and downstream pipeline will be created.

Viewing the changes

Here, we have created a new trigger job and retried it, which means the pipeline should now have 2 downstream pipelines. However, we expect to only see 1 downstream pipeline (the latest one) in the pipeline graph and mini pipeline graphs, instead of 2. Here is how to access the affected pages.

Pipeline Editor

1. Visit CI/CD > Editor from the sidebar.

Pipelines Table

1. Visit CI/CD > Pipelines from the sidebar.

Commit Page

1. Visit the commit page of the commit you made when updating your .gitlab-ci.yml.

MR Widget

1. Create a merge request from the branch where you made your .gitlab-ci.yml changes.

Pipeline Graph

1. Visit the pipeline that was created from your commit. The link can be found in the Pipelines Table, or the View Pipeline button in the pipeline editor.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.