Approval rules in Managed Service for GitLab
With Managed Service for GitLab, you can flexibly set up mandatory approval rules before any code can be added to the target branch of the project. This feature is an alternative to the Approval Rules Enterprise Edition tool built in GitLab and is available regardless of the GitLab version.
If a GitLab instance has the approval rules enabled, Managed Service for GitLab analyzes approvals by reviewers for compliance with the specified rules. If there are not enough approvals, a thread is created in a merge request that blocks it from being merged to the target branch. Editing the merge request creates or updates a comment in the thread with its current compliance status. Once all the required approvals are obtained, the thread is closed.
If you close a thread manually, it will be created again. If a merge request is approved regardless of the existing rules, users with the Maintainer role or higher will receive an email notification about the violated code approval workflow.
For more information about working with approval rules, see Setting up approval rules.
Use cases
GitLab Token
You need a GitLab token to set up approval rules. A token is requested for authorization when working with the repository: this is how the GitLab API is accessed.
A GitLab token has a lifetime, which is set when creating the token. The lifetime expires at midnight UTC on the specified day. The maximum lifetime is one year from the token creation date.
One day before the expiration date, GitLab sends a notification that the token is about to expire. The notification is emailed to the account by which the token was created.
Issue a new token and add it to your GitLab instance settings before the previous token expires. Otherwise, Managed Service for GitLab will not operate correctly.
Use cases
Available configurations
Note
The configuration you select affects the cost of using the instance's computing resources.
You can choose a suitable configuration based on your team's objectives:
- Basic: Allows you to create a single rule for each project with no additional conditions. It is suitable for small teams (up to 10 people).
- Standard: Allows you to configure multiple rules for each project and assign code owners to individual files or directories (up to 10 records). It is suitable for medium-sized teams (10 to 30 people).
- Advanced: Includes all features of the standard configuration with no limit on the number of code ownership records and allows setting up different approval rules for different project branches. It is suitable for large teams (over 30 people).
See the table below for a more detailed comparison of what different configurations provide:
| Features | Description | Basic configuration |
Standard configuration |
Advanced configuration |
|---|---|---|---|---|
| One approval rule per project | You can assign reviewers, one of whom must review new commits before merging branches. | |||
| Protected branches | You can select the branches for which the approval rules will apply. | |||
| Code Ownership | You can assign individual files and directories (including by mask) to specific users. These users become code owners and can participate in code approval if commits in the merge request affect their files. | |||
| Multiple approval rules | You can set more than one approval rule per project. | |||
| Branch-specific rules | You can specify different approval rules for different branches, e.g., release and master. |