<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> Problem to solve --- <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> Many compliance-minded organizations leverage external services when building, testing and deploying code. These external services perform various checks (e.g. code quality, security scanning, change control) that are detached from the GitLab merge request. Currently, there's no way to aggregate this external information and make these outputs a consideration during the approval process. This creates a disjointed experience for MRs in complex compliance environments and requires additional work by our customers to stitch this data together. Intended users --- * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) Job statement --- > When I have complete visibility into adherence of policies, I want to monitor the condition of our software development practices, so that I can address issues before they become more problematic. Short term vision --- | Form to create check | List of statuses to check | Checks within a Merge Request | | -------------------- | ------ | --- | | ||| Implementation plan for MVC (Behind Feature Flag) --- #### Restructure the layout of the Approval rule form. | Status | Issue | Milestone | | ------ | ----- | --------- | | `Closed` | ~frontend [Restructure layout of Add approval rule form](https://gitlab.com/gitlab-org/gitlab/-/issues/301172) | %13.10 | #### Allow approval rules to accommodate both user and API approvers. | Status | Issue | Milestone | | ------ | ----- | --------- | |`Closed`|~frontend [Add ability to CRUD an "Approval Gate" approval rule on a Project (FE)](https://gitlab.com/gitlab-org/gitlab/-/issues/300973) | %13.11 | |`Closed`|~backend [Add ability to add an "Approval Gate" approval rule to a Project (BE)](https://gitlab.com/gitlab-org/gitlab/-/issues/267511)| %13.10 | |`Closed`|~backend [Add ability to create External API Approver](https://gitlab.com/gitlab-org/gitlab/-/issues/230731)| %13.11 | |`Closed`|~frontend [Replace "Approval Gate" term with "Status check"](https://gitlab.com/gitlab-org/gitlab/-/issues/327627)| %13.12 | |`Closed`|~frontend [Expose “Approval Gate” in creating/editing a Merge Request
](https://gitlab.com/gitlab-org/gitlab/-/issues/327626)|| |`Closed`|~backend [Execute Approval Gates webhook on MR change](https://gitlab.com/gitlab-org/gitlab/-/issues/267517)| %13.11 | #### Display API status checks in a Merge Request. | Status | Issue | Milestone | | ------ | ----- | --------- | |`Closed`|~backend [Execute Approval Gates webhook on MR change](https://gitlab.com/gitlab-org/gitlab/-/issues/267517) | %13.11 | |`Closed`|~backend [External MR Approval API to accept callbacks from Approval Services](https://gitlab.com/gitlab-org/gitlab/-/issues/267519), ([API docs](https://docs.gitlab.com/ee/api/merge_request_approvals.html#approve-merge-request))| %13.11 | | {Missing} | ~backend Create documentation to explain how an external API Approval Service should respond to determine its status. | | `Closed` | ~frontend [Display Status checks as a non-blocking Merge Request Widget](https://gitlab.com/gitlab-org/gitlab/-/issues/327634) | | | `Closed` | ~backend [API to list external approval rules for a merge request](https://gitlab.com/gitlab-org/gitlab/-/issues/328211) | %"13.12" | #### Differentiate API status checks from Approval rules | Status | Issue | Milestone | | ------ | ----- | --------- | |`Closed`|~frontend [Migrate “Status checks” to go under Settings > Merge Requests, after Merge checks](https://gitlab.com/gitlab-org/gitlab/-/issues/327638)| %13.12 | |`Closed`|~documentation [Document how to use status checks and update learn more links](https://gitlab.com/gitlab-org/gitlab/-/issues/329517) | %14.0 | Stretch Goals --- Reduce ~"technical debt" in Approval Rule Modal | Status | Issue | Milestone | | ------ | ----- | --------- | | `Closed` | ~frontend [Update RuleForm inputs to use GlInput and GlFormGroup](https://gitlab.com/gitlab-org/gitlab/-/issues/323729) | %13.11 | | `Open` | ~frontend [Update ApproversSelect to use GlSearchBoxByType and remove the jQuery and Select2 dependencies](https://gitlab.com/gitlab-org/gitlab/-/issues/323923) | | --- ### Licensing --- ~"GitLab Ultimate" Is this a cross-stage feature? --- :handshake: ~"group::compliance" ~"group::source code" ~"group::code review" Have feedback on this feature? Please share your thoughts [here](https://gitlab.com/gitlab-org/gitlab/-/issues/250742). <!-- 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 -->