Skip to content

Confirmation for manual CI actions

Update (18th Jun 2024)

This is available on .com and will be available with 17.1 release on Self Managed. See instructions (https://docs.gitlab.com/ee/ci/yaml/#manual_confirmation) Please provide feedback as a comment on this issue.

Description

I have a few jobs in my deployment pipeline that I would classify as destructive (i.e. delete the stack). While these are manual actions that I have to click to run, I'm still a little bit worried about accidentally triggering them. At the moment, if I accidentally trigger them, I have to go into the job and cancel it before it gets to the dangerous part.

Proposal

I would like an optional confirmation step for manual actions. Perhaps something like:

delete_job:
  stage: post-deployment
  script:
  - make delete
  when: manual
  manual_confirmation: Are you sure you want to delete $CI_ENVIRONMENT_SLUG?

When I click the delete job play button, a confirmation modal or popover or something is displayed, asking me to confirm my choice.

Technical Implementation Guide

We would have to update the following locations:

  • Pipeline table in Build -> Pipelines

Screenshot_2024-03-05_at_12.43.47_p.m.

This applies to both the manual actions and the mini pipeline dropdown.

Screenshot_2024-03-05_at_1.17.00_p.m.

  • Pipeline tab in the Merge Request page
  • Pipeline tab in the Create Merge Request page
  • Commit page
  • Pipeline details page

There's also the "Jobs" tab on the Pipeline page, and the "Play all manual" button on the pipeline view.

There are a bunch of places where a manual job can be played from, FE need to do a search for anywhere that triggers a "play manual" or "play all manual" type of request.

Future iterations

If we allow custom messages, as a first iteration, we should allow only text messages without HTML. If the demand is high enough, we might get requests to permit labels or other HTML-based content in the alert message.

Concerns

Security-wise, we should escape everything the user provides; allowing custom messages from a user can be a potential attack vector, resulting in HTML injection attacks.

Edited by Rutvik Shah