Introduce compliance checks into merge requests
We're thinking about project-level compliance in &2087. As part of this vision, we need to consider how we define elements of a project-level policy: but also how we enforce adherence to these policies in a project.
One of the channels for this enforcement should be the merge request. We should be able to set a variety of policies at the project level, and allow exceptions to these rules to be surfaced in the MR so the author or reviewer can take appropriate action to resolve these issues prior to merge.
Some customers rely on a CI pipeline to manage compliance checks, which was part of the motivation for introducing #8429 (closed). While forced includes may definitely have some utility, it's a better pattern for productivity and velocity to keep a pipeline as lean as possible. Adding more jobs that are not related to the quality of the code gives pipelines more opportunities to fail, makes failed pipelines harder to troubleshoot, and does not support faster cycle time.
The approach in this issue may deprecate the availability of forced includes when implemented.
- I want to see that QA engineers approved a MR as a visual element in the MR widget
- I'd like to see external service approvals confirmed in the MR widget
This issue asserts that compliance-related checks do not belong in a CI pipeline, but should be provided in a separate section of the merge request.
- Introduce a dedicated section in merge requests specific to compliance related checks.
For this iteration, the proposal surfaces this information but does not enforce compliance. In future iterations, we'll consider how we enforce compliance with policy rules and allow for certain users to override compliance guidance and merge.
- Which compliance rules should we start with?
- Should we introduce system hooks for external services?