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.](https://gitlab.com/gitlab-org/gitlab/uploads/420845b71337878e0b4251000747bbba/Screenshot_2024-03-05_at_12.43.47_p.m..png) This applies to both the manual actions and the mini pipeline dropdown. ![Screenshot_2024-03-05_at_1.17.00_p.m.](https://gitlab.com/gitlab-org/gitlab/uploads/f53b4668d7acb98a31f3fbf7ed15f993/Screenshot_2024-03-05_at_1.17.00_p.m..png) * 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.
issue