CentOS Stream Kernel Documentation
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  1. CentOS Stream Kernel Documentation
  2. /
  3. Docs
  4. /
  5. Merge Request Approvals and Blocks

Merge Request Approvals and Blocks

1. Approving a Merge Request via GitLab Web interface

Reviewers can use GitLab’s Approve interface to approve Merge Requests as this allows the maintainers, managers, and product owners to use the GitLab WebUI or tools to view the approvals for each merge request.

The WebUI has an “Approve” button that is available to users with sufficient permissions to review Merge Requests.

Here are some examples of what that "Approve" button might look like:

1.1. Example being the first to approve

approvals webint approve initial

In this above image, this is what to expect to see when there aren’t any existing approvals on the MR.

1.2. Example approving in addiiton to others who have already approved

approvals webint approve additionally

This image shows an MR that should already be satisfied enough to merge, but the option to approve additionally is also available.

1.3. Example being ineligible to provide an approval

approvals webint approve ineligible

This image shows what the approval interface looks like when the necessary privilege is missing to provide an approval.

🛈
 There are various reasons for being ineligible to review a MR including (but not limited to) being the original author for this MR, and also not having developer permissions to the project.

2. Approving a Merge Request using the 'lab' utilities

This action can also be completed in lab by executing:

lab mr approve <mr_id>

3. Blocking a Merge Request with a Blocking Thread (aka "soft block")

There are currently two different ways to block an open MR. The first is to open a GitLab blocking thread which needs to be resolved prior to the MR being able to get merged.

❗
 GitLab blocking threads can be resolved by any user. GitLab blocking threads have no requirement that the thread be resolved by the thread author or the merge request author. As such, GitLab blocking threads should be only be used when a response is not considered critical to the resolution of the merge request.

Here are a couple of examples to understand what a blocking thread involved MR looks like:

3.1. With unresolved blocking threads

approvals unresolved thread

In the above image, this MR will not be able to get merged until that 1 unresolved thread is marked as resolved.

3.2. With all blocking threads resolved

approvals resolved thread

As displayed in this image, there were some blocking threads opened, but they have all been resolved. Therefore, this MR will not be blocked from getting merged due to a blocking thread.

3.3. A freshly opened blocking thread

approvals blocking thread opened

In the above image, this is what would be expected on a freshly created blocking thread from the comments portion of the MR.

3.4. Another freshly opened blocking thread (started from within code review)

approvals blocking thread opened alt

This image shows that blocking threads can also be started from within the code while doing a review, which allows for providing some additional context.

3.5. A resolved blocking thread

approvals blocking thread resolved

The above image shows what a blocking thread looks like once it has been blocked. Note that the list of comments has been collapsed and there is no "Resolve thread" button available.

4. Blocking a Merge Request with the /block keyword (aka "hard block")

The other way to block an open MR is to add a comment with /block in its contents (alone on the start of a line). This is enforced by adding an approval rule (near the Approve button) that must be satisfied before the MR can be merged.

❗
 Comments created with '/block' can only be resolved by the comment author or a maintainer. '/block' comments must be used when the commentor wants to prevent the merge request from being merged. This 'hard block' is much stricter than the 'soft block' GitLab mechanism described above. In the unusual case that a maintainer has to resolve a '/block' thread, management and senior engineering staff will be consulted on resolving the thread.

4.1. Example using /block keyword

approvals blocked keyword

The effect of this /block will have the CKI KWF Bot set the Acks::Blocked label if there are still unresolved /block operations. This is also reflected on the Ack/Nack summary comment.

4.2. Example of the Approval Rule showing up on a blocked MR

approvals blocking approval rule

4.3. Example of the Approval Rule noted by the Ack/Nack Comment

approvals blocked acknack

5. Unblocking a Merge Request with the /unblock keyword

An important distinction to note between using /block and blocking threads is that only the originaly person who applied /block can apply the corresponding /unblock.

5.1. Example using /unblock keyword

approvals unblocked keyword

Note that in this particular image, the Acks are not satisfied, but the Acks::Blocked label has been removed by the /unblock.

6. Unblocking a Merge Request with the Approve button

An MR that has been blocked via the /block functionality can also be unblocked by using the Approve button as detailed in Approving a Merge Request via GitLab Web interface

gdoc_arrow_left_alt What is a GitLab Fork? Kernel Variant Jira Process gdoc_arrow_right_alt