Confirmation for manual CI actions

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
  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.

@tommy.brunn Thanks for the proposal. Let's see if it gains any traction

/cc @grzesiek

added CI/CD feature proposal pipeline labels

/cc @bikebilly

@bikebilly I think an extra confirmation is a good idea in general. You already put a lot of thought in these actions by defining them.. they therefore can have quite severe effects. This makes it so, UI deficiencies or strange actions can not set such actions in motion per accident.

Agreed on the cancel part as well (but only for manual action jobs).

I thought we already had a pop-up confirmation? cc: @filipa

For manual actions we don't.

I am not 100% sure if we should. Recently @sarrahvesselov suggested against confirmation boxes: https://gitlab.com/gitlab-org/gitlab-ce/issues/35821

And I agree with her. In this case specifically I am not sure of how annoying this could be, not all manual actions are disruptive. Imagine if it is something you have to do all day

@sarrahvesselov what do you think?

I would really hesitate to add a confirmation by default for all manual actions. I would be incredibly annoying in the case of non-disruptive actions.

A confirmation action is really only appropriate when there is no good way to undo actions. Consider archiving an email in gmail, where instead of asking if you're sure you want to archive the email, gmail immediately shows you a link to unarchive the email in case you accidentally archived it.

In the case of CI jobs, I don't see a way to undo the action, considering that they can trigger arbitrary side-effects, which means that a confirmation may be unavoidable.

This is why I suggested that the confirmation be configurable and optional. That way if the action does not have disruptive side-effects, the author can simply manually cancel the job if they accidentally triggered it, and if they don't manage to do so before it has completed, it's not a big deal. If the action is disruptive in some way, the author can configure a confirmation action so that they can prevent it from executing accidentally. This way there is no additional friction for non-disruptive actions.

@filipa @dimitrieh @bikebilly

In general, I like to avoid unnecessary extra steps like 'Click to Confirm'. They quickly become disruptive to the workflow and can have a big impact on what should be a quick task to perform. In this case, we are talking about a destructive action that could be difficult to undo. This also presents an annoying and possibly detrimental user experience.

It sounds like the best user experience here would be to:

1. notify the user that the action has occured (in case it was accidental)
2. give them the ability to 'undo' the action by clicking 'undo'
3. or do nothing and the message disappears
4. or cancel/delete the message before it disappears

This would apply only to destructive actions. The toast message we are implementing would be a good fit for this. https://gitlab.com/gitlab-org/gitlab-ce/issues/35741

This is why I suggested that the confirmation be configurable and optional.

We prefer convention over configuration @tommy.brunn except in the most extreme cases. I believe the solution above would sufficiently solve the problem.

@sarrahvesselov: That would be a great solution for undoable actions, but my use case is one where it's not possible to undo the action, in which case a toast message doesn't really help.

Thanks for the clarification @tommy.brunn @bikebilly. I read through again and see that you did indeed mention this Tommy, my apologies for making you repeat yourself.

I do not believe that we should add a confirm for every manual action and we do not want to create an overly complex UI by adding configurable options.

Have you accidentally triggered one Tommy or is this something you are just concerned about at this point?

I haven't done it on Gitlab yet, but I've only been using Gitlab CI for a few weeks for a single project. I have however done it and have seen it done plenty of times in Jenkins pipelines, which I've been using for years.

I'd like to second the request for either a configurable or default confirmation dialog. While the pipeline features work really well, I've been really worried to accidentally retry an old production deploy, which could lead to catastrophic results.

mentioned in issue #27333 (moved)

moved to gitlab#11275

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue