Skip to content

Retry failed and canceled jobs in downstream pipelines

Mireya Andres requested to merge retry-failed-dsp-jobs into master

What does this MR do and why?

For #32559 (closed)

A trigger job (or bridge job) is a job whose purpose is to trigger/create a downstream pipeline. When the user goes to the show page for a trigger job and clicks on the Retry button, this will retry all the failed and canceled jobs in the downstream pipeline. If the downstream pipeline already succeeded, then the retry button is disabled.

Note that the default behavior for trigger jobs is that the status will become success when the downstream pipeline is created. The status of the trigger job is not synced or dependent on the status of the downstream pipeline.

No changelog added since this feature is behind a feature flag.

Screenshots or screen recordings

Status Recording
Retrying a downstream pipeline successfully success
When an error occurs error
When downstream pipeline is already successful (no failed/canceled jobs) disabled

How to set up and validate locally

  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: 
    stages:
  - build

triggerJob:
  stage: build
  trigger:
    include:
      - project: "/path/to/project" # replace with another project
        file: ".gitlab-ci.yml"
  3. Make sure the .gitlab-ci.yml file of your child project is set to fail. For example: 
    stages:
  - build

job:
  stage: build
  script: asdfghjkl # this will fail
  4. Run the pipeline from the parent project and wait for the pipeline to finish running. The pipeline will fail and the downstream pipeline should also fail.
  5. Visit the pipeline and click on the triggerJob job pill. This should take you to the job page for triggerJob.
  6. Click on the Retry button in the sidebar.
  7. This will re-run the failed jobs in the downstream pipeline. You will be redirected to the downstream pipeline, where the status should be back to running.

MR acceptance checklist

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

Merge request reports