Merge Request approvals in GitLab CE

Question

We would like to use Merge Request approvals similar to how it works in Stash where one person creates a PR and can assign multiple reviewers who can approve or decline. PR can be merged only when N reviewers approved (configurable per repository).

It seems that this feature is offered only in GitLab EE, is that right? Is there any free or cheap alternative to migrating from CE to EE?

Perhaps a custom GitLab fork or an addon/plugin?

Special

Answer 1

Even though Merge Request Approvals are not part of the Free GitLab tier, the functionality is still available on the Merge Request user interface and data is available in the API, so as a workaround you can create a GitLab CI job that implements checking the number of approvals and fails if insufficient.

First, ensure that in your project's Merge Request settings, Pipelines must succeed is enabled.

Then create a new job in .gitlab-ci.yml that will fail when there are insufficient merge request approvals:

code_approved:
  rules:
    - if: $CI_MERGE_REQUEST_ID
  script:
    - apt-get update
    - apt-get install -y jq curl
    - >
      curl --header "JOB-TOKEN: $CI_JOB_TOKEN"
      "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/approvals" 
      | jq -e '.approved_by[0]'

• apt-get ... : Install the curl and jq binaries.
• curl --header "JOB-TOKEN: $CI_JOB_TOKEN": authenticates the call.
• "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/approvals" GitLab API endpoint returning approval data for the current merge request. Note that on GitLab Free, a lot of data returned by this resource is missing or misleading, but approved_by is properly populated.
  You can also visit this API URL in a browser window to preview, e.g. https://gitlab.com/api/v4/projects/blaisekal%2Fmr-approvals/merge_requests/1/approvals
• | jq -e '.approved_by[0]' pipes the output to jq, attempts to fetch the first approved_by item from the list. -e ensures that when it cannot find that item, the command will return with an error exit status, which causes the CI job to fail, which causes the option to merge to be blocked. If you require two approvals, use jq filter '.approved_by[1]'.

---

Demo: https://gitlab.com/blaisekal/mr-approvals/-/merge_requests

---

The biggest disadvantages of this workaround are that you need to run a job to determine approved status, you have to re-run the job manually if the number of approvals changes, and a malicious member of your team could remove the CI job before merging.

Catenane

We should choose this answer, it works – Nonchalance

Answer 2

We understand, but we are only shipping this with GitLab EE because we think typically locking the workflow as it does, is more interesting for larger organisations.

In a small team, it's much easier to agree on a certain workflow with each other, making it less important to have a tool that is strict and more favorable to have something that is flexible.

In your team, you could consider using 'thumbsup' (by writing :+1:) as a tally for approvals and agree amongst yourselves for a minimal value. The +1's will be summed in the MR.

© Job van der Voort

UPDATE Sep 2020 Now there're merger request approvals in Core - Introduced in GitLab 13.2

But they are optional. You cannot assign it to some user.

Ectogenous

Not an answer to the question. – Unloosen

Answer 3

As far as I know you can't migrate from CE to EE, as CE is free and EE isn't.

But what you can do is:

1. Use GitLab.com, from which you'll have all EE features available for free;

2. I never tried CE before, but you'll probably find these features there:

   • Add users to the project and give them different access levels. To the levels you can define which are allowed merging or not;
   • Assign merge requests for specific users, so that only the assignee is allowed to merge;
   • Open issues before adding a MR related to that issue, so people can discuss the outlines on the issue before adding a MR. When you add an issue number to a committed message, that issue will be automatically closed when merging.

I'm not sure this is the answer you're looking for, but I hope it helps.

Telegram

This answer is out of date. It is possible to migrate between CE and EE. – Haydon

Answer 4

That is currently not possible. And I do not know of any plugin to implement it.

You can upvote with a "thumbs up" reaction (and subscribe to) the already existing issue and discussion on that matter:

https://gitlab.com/gitlab-org/gitlab-ce/issues/42096

Streusel

Answer 5

From what I gathered trying to solve this issue with Merge request approvals, there is no way other than upgrading the GitLab instance.

Tried to get the number of approvals using V4 GitLab API as mentioned in the accepted answer, but that can be done, only if the project is public, which is not possible in my case, as my project has to be private.

Source: https://stackoverflow.com/a/44469417

The CI_MERGE_REQUEST_APPROVED variable doesn't work either as it is only available with the higher tier of GitLab.

Source: https://stackoverflow.com/a/77413313

Cobalt

Answer 6

You can overcome this limitation with writing script and use it in CI/CD pipeline. There is comprehensive information in here: https://gitlab.com/shell-script2643007/check-approval/-/blob/main/README.md

Daman

Answer 7

This could be implemented by using a custom webhook receiver that listens for MR events, and then uses the GitLab API to check the number of approvals on the MR. If the desired number of approvals is not met, the webhook can post a comment on the MR. When the MR is approved, the webhook can automatically resolve the MR comment discussion. As long as the setting "All discussions must be resolved" is enabled in the project settings, this effectively blocks the MR from being mergeable until the desired number of approvals are met.

Of course, there is nothing stopping a developer from simply resolving the webhook's comment and then merging. But it's slightly better than nothing.

If you are using a self-hosted GitLab instance, you could go one step further and implement a git pre-receive hook that checks the MR approvals and rejects the merge.

Stirling