Block merging if there are failed status checks

Problem Statement

Preventing changes from being merged prematurely relies solely on trust. Users can disregard a failed status check and proceed with a merge anyway which is inhibiting adoption of this feature as a means for enforcement.

Several customers have requested to be able to block merging if a status check has failed. A concern with the existing implementation is that project maintainers could disable a status check as a way to work around failing checks.

Solution proposal

Introduce a setting so that if all external status checks have not passed, then block merging of the MR. Notably, if a status check is pending, do not allow the MR to be merged. Pending should be considered "not passed," just like failed status, so should not allow the MR to merged until the status checks return a successful state.

This setting should be available at both the project and group-level. If set at the group-level, it should cascade down like other MR settings do currently.

Merge Check checkbox

Please also see the attached design files.

Add a checkbox to the Merge Checks section at both the project and the group level. When checked, prevent an MR from being merged until all external status checks have indicated passing status. If there are 0 external status checks for an MR, this checkbox should do nothing.

This setting should behave the same as all the other settings with respect to what happens if a group has the value set or not and how that cascades down to a project.

Other ideas considered

Merge Request Approval checkbox

Update: Not a good fit, since we don't expect users to interact with the 3rd-party tools within GitLab.

Add a new checkbox to the existing MR Approvals section

Add a checkbox to the MR approvals settings section at both the project and group level. This setting should behave as the same as all the others with respect to what happens if the group has a setting and how it impacts child projects with cascading settings.

Security & Compliance policy

Update: Not ready to go down this road yet based on the comment below.

Screenshot of what the policy editor update might look like

_Collaborate with @sam.white to fill this out_

License tiering

GitLab Ultimate

Customer references

• https://gitlab.my.salesforce.com/001610000111bAR
• https://gitlab.my.salesforce.com/0016100000AYw37
• https://gitlab.my.salesforce.com/00161000004aqpn
• https://gitlab.my.salesforce.com/00161000004zrG3
• https://gitlab.my.salesforce.com/0064M00000ZrFs4

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Implementation plan

• backend weight 3️⃣
• frontend weight 4️⃣

1. Recommended - Add a new feature flag since this has potentially high impact (blocking merge requests).
2. backend Add a new project-level setting.
3. frontend Add a checkbox for the new project-level setting.
4. backend Block merge requests from being merged if the setting is enabled and status checks are not passing.
5. backend Add the value of the setting in the merge request poll cached widget entity.
   • Note: See !55553 (merged) as an example.
6. frontend Add a new merge request state for status checks.
   • Note: See !58658 (merged) as an example.
   • Note: Status check results are currently fetched async in the widget extension. Ideally we can share the response with the MR state, and thus only request the data once.
   • Note: We'll also need to set the checking status and display the MRWidgetChecking widget while the status check results are busy fetching.
7. Update specs.
8. Update documentation.