## Problem Statement <!-- What is the problem we hope to validate? Reference how to write a real customer problem statement at https://productcoalition.com/how-to-write-a-good-customer-problem-statement-a815f80189ba for guidance. --> 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. <details> <summary>Other ideas considered</summary> #### ~~Merge Request Approval checkbox~~ Update: Not a good fit, since we don't expect users to interact with the 3rd-party tools within GitLab. <details><summary>Add a new checkbox to the existing MR Approvals section</summary>  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. </details> #### ~~Security & Compliance policy~~ Update: Not ready to go down this road yet based on [the comment below](https://gitlab.com/gitlab-org/gitlab/-/issues/340855#note_901400065). <details><summary>Screenshot of what the policy editor update might look like</summary> _Collaborate with @sam.white to fill this out_  </details> </details> ## License tiering gitlab~3207279 ## 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 <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ## Implementation plan 1. ~backend :three: https://gitlab.com/gitlab-org/gitlab/-/issues/369859+ 1. ~frontend :one: https://gitlab.com/gitlab-org/gitlab/-/issues/369860+ 1. ~frontend :three: https://gitlab.com/gitlab-org/gitlab/-/issues/369861+ 1. ~frontend :four: https://gitlab.com/gitlab-org/gitlab/-/issues/381637+ 1. ~"feature flag" TBA and integration