How to write custom GitLab approval rules?

Question

My team is using GitLab Premium. In the project settings, under Merge request approvals, there is an Approval rules section. In the first row, we increased the Approvals required number to 1 so that every merge request must be approved by at least one other teammate. So far so good.

I can see there is also a License-Check rule and Coverage-Check rule that can be enabled and what they do is pretty self-explanatory. There is also an Add approval rule button where you can set a name and approvers for a new rule, but you can't actually describe/choose what the actual rule should be. All the documentation I could find simply explains how to click around that UI.

How do you actually set new rules and is it possible to write own custom rules?

For example, we'd like to set a rule that only a subset of the team can approve "large" merge requests (where "large" is defined by the number of lines changed, as reported by git log). I imagine that would be something similar to License-Check or Coverage-Check, but written by us. Is that possible?

Answer 1

I don't think this is possible yet. For now, approval rules are branch-specific. The content of a merge request doesn't matter.

Nevertheless, I think there is a solution for you: GitLab allows you to write bots that can access the GitLab API. What you'd need is an external service listening to new merge requests. Your tool would then have to find out in some way how many changes were actually made (this is not yet possible with the Merge Request API as far as I can tell). Depending on this, you can then adjust the approval rules via the API for the corresponding MR (API reference).

Does this approach help you?

You can also ask a question in the GitLab Community Forum, there you might get better help.

Answer 2

Now I understand the point of Add approval rule (it's only to define a set of approvers for a given branch, nothing more than that).

Actually, an Approval Rule would apply to a branch, or all branches or, since GitLab 15.3 (August 2022):

Add approval rules for all protected branches

You can now create an MR approval rule and apply it to only protected branches in your project.
This is a great improvement that allows you to more selectively apply compliance controls with increased granularity.

Previously, adding an MR approval rule would apply it to all branches. This was a great way to ensure that proper workflows were enforced before code reached production, but it also meant that MRs for feature branches, short-lived branches, or experimental branches all had to use the same workflow.
This could slow down developers that did not intend to commit to protected branches and who likely did not need the same level of workflow enforcement.

Creating MR approval rules for protected branches allows you to be confident that the sensitive branches you depend on will have proper workflows applied to them while not slowing down development on other branches that do not need the same level of control.

See Documentation and Issue.

But that differs other rules, which cannot easily be replicated through Approval rules.

---

GitLab 15.9 (February 2023) provides a new option, but only for Premium or Ultimate:

Require multiple approvals from Code Owners

You can now precisely define for which files, file types, or directories approval has been designated as optional, required approval by one user, or by multiple users. The latter being the new improvement of the CODEOWNERS file.

So far, if you needed to require multiple approvers be it for compliance reasons or other reasons, you could only do so with an approval rule.

However, unlike Code Owner approvals, approval rules apply to entire branches and cannot be refined to apply to specific parts of your code base. So, the multiple approvals would have also been required for changes that do not need a high level of scrutiny leading to unnecessary reviews.

See Documentation and Issue.

Note that License-Check is deprecated (to be removed in GitLab 16.0+).
GitLab Ultimate proposes flexible license approval policies.