Dynamic Merge Request Approvals

Release notes

Merge Request Approvals are a great way to ensure compliance of changes, but they lack a lot of flexibility. They were extended to add a few basic rules, like gating critical vulnerabilities or denied licenses. We could make them a lot more flexible, to support the vast majority of scenarios imagined by our users. With this new feature, they would be able to dynamically add new approvals from the pipeline, without using the GitLab API. It will lead to many new usages in GitLab.

Problem to solve

As a developer, I want to loop in the right groups or person when certain conditions are met. Their approval could be added on the fly, once the pipeline succeeded.

Intended users

• Cameron (Compliance Manager)
• Parker (Product Manager)
• Delaney (Development Team Lead)
• Presley (Product Designer)
• Sasha (Software Developer)
• Devon (DevOps Engineer)
• Sidney (Systems Administrator)
• Sam (Security Analyst)
• Rachel (Release Manager)
• Alex (Security Operations Engineer)
• Simone (Software Engineer in Test)
• Allison (Application Ops)
• Priyanka (Platform Engineer)
• Dana (Data Analyst)
• Eddie (Content Editor)

(yes, all of them)

User experience goal

The user should be able to generate an artifact which will add new approvals to the current Merge Request. Existing approvals can't be updated/deleted by this process.

Proposal

Similar to the workflow designed in this issue (/cc @mattgonzales), a report artifact should allow to interact with GitLab when being parsed. New approvals would be required if defined in this artifact, involving directly groups or specific users.

Example of workflow ("GateKeeper" being a custom job created by the users):

graph LR
  A[SAST] -->|JSON Report| D
  B[Dependency Scanning] -->|JSON Report| D
  C[Business Compliance] -->|JSON Report| G
  D[GateKeeper] -->|JSON Report| G
  G[GitLab Parser] -->|New Approvals| MR[MR updated]

Further details

This new feature opens a lot of new routes to explore, for example:

• Dependency Gates (/cc @estrike): New dependencies would require the approval of the GitLab AppSec team.
• GitLab-CI JOBOWNERS (similar to CODEOWNERS, but more flexible)
• Compliance gates
• Smarter Merge Request Security Approvals. Currently limited to pre-defined rules, and broken is many ways. We would let the users define when they want to gate (request approval), and how.

And so on, the list can grow indefinitely.

Permissions and Security

• Add expected impact to members with no access (0)
• Add expected impact to Guest (10) members
• Add expected impact to Reporter (20) members
• Add expected impact to Developer (30) members
• Add expected impact to Maintainer (40) members
• Add expected impact to Owner (50) members

Documentation

No permission required, only the existing ones to be able to change the GitLab-CI configuration file(s).

Availability & Testing

TBD.

What does success look like, and how can we measure that?

We can measure 2 different things here:

• The number of applied approvals, added from the artifacts.
• The number of new features based on this one.

What is the type of buyer?

GitLab Ultimate ?

Is this a cross-stage feature?

TBD.

Links / references