Skip to content

Add ability to approve builds configuration for protected runners

Description

The problem described in gitlab-ce#20826 hurts us so much, so we are looking for the ways to fix it and found one that should resolve many of disadvantages from previous one.

Proposal

What do we propose:

  • Add checkbox to project (or shared) runners to "protect" them (as already proposed in gitlab-ce#24196).
  • Introduce new entity: "approved build configurations" for project.
  • Add configuration to project for user level allowed to approve build configurations (developers or masters or only owner).
  • Add new state waiting_for_approval for builds.

So the use case should be:

  • Someone pushes code.
  • The pipeline and appropriate builds are created according to .gitlab-ci.yml.
  • Then gitlab looks for runner as usual. If protected AND non-protected found, then non-protected is used and everything goes like it do now.
  • If only protected found, build goes to it and new workflow is applying:
    • Before running build, gitlab looks into approved build configurations for this build.
    • If there is an approved configuration it compares it with current (by hashsum for simplicity). If it matches — build starts. If it does not match or there is no approved configuration — build moves to waiting_for_approval.
    • Users with configured permissions can see and approve them.
    • After approval all appropriate builds move to pending and try to run again.

About "approved build configuration".

  • Object should contain the name of build and hashsum of configuration. But maybe it should have all configuration in some form to show it in UI.
  • There should be separate page in project where users with configured permissions can view approved build configurations and waiting for approval builds and can approve them.
  • After approving build its configuration is saved as this object. Then all builds with same configuration will start automatically.
  • There can be several approved configurations for same build (for working on CI configuration in different branches). All of them should be treated as approved configuration.
  • There should be way to disapprove configuration (delete this object).

This approach allows:

  • developers to change and run all testing builds on non-protected runners without touching masters and owners like now;
  • masters and owners to protect deployment process and control changes to each part separately and independently, moreover it's done only once per change.

Additionally, there may be configurable option to autoapprove new build configuration if it was pushed by user with required permissions. Someone wants process to be more convenient by reviewing changes only in merge requests and after that they are treated as already approved, someone needs review every configuration change explicitly.

Thanks to @distol for the original idea. If this proposal seems applicable for you we'd be glad to implement this and ready to start now.

~"feature proposal" CI gitlab-ce2779335

/cc @markpundsack