Approval rules in Managed Service for GitLab
With Managed Service for GitLab, you can flexibly set up mandatory approval rules before merging code into the target branch of the project. This feature is an alternative to the GitLab Enterprise Edition’s Approval Rules tool and is available regardless of the GitLab version.
If approval rules are enabled in your GitLab instance, Managed Service for GitLab analyzes obtained approvals for compliance with the specified rules. If there are not enough approvals, a blocking thread is created in the merge request, preventing it from being merged into the target branch. When the merge request is updated, a comment with the current compliance status is created or updated in the thread. Once all required approvals are obtained, the thread is resolved.
If you manually resolve the thread, it will be recreated. If the merge request is approved regardless of the existing rules, users with the Maintainer role or higher will receive an email notification about the violated 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. When accessing a repository, a token is required for authentication, allowing GitLab API calls.
A GitLab token has a lifetime, which is set when creating the token. The token expires at 00:00 UTC on the specified date. The maximum lifetime is one year from the token creation date.
The day before the expiration date, GitLab sends a notification that the token is about to expire to the email address of the account that created the token.
Issue a new token and add it to the GitLab instance settings before the current token expires Otherwise, Managed Service for GitLab will not work correctly.
Use cases
Available configurations
Note
The configuration you select affects the cost of using the instance 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. This option is best suited for smaller teams (up to 10 people).
- Standard: Allows you to configure multiple rules for each project and assign code owners to specific files or directories (up to 10 entries). It work best 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 entries, and allows setting up different approval rules for different project branches. This configuration is a fit for 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 a user group, with at least one member required to approve the merge request before merging. | |||
| Protected branches | You can select branches the approval rules will apply to. | |||
| Code Ownership | You can assign specific files and directories (including using patterns) to particular 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. |