Draft: POC - Approval coverage rule [RUN ALL RSPEC] [RUN AS-IF-FOSS]
Ref:
What does this MR do?
This POC
demonstrates how we could add a new merge request approval rule for code coverage base on an existing coverage report generated by GitLab CI.
graph LR
subgraph "Report comparison"
Flow1[Build comparison between head and base] --> Flow2
Flow2[Determine if violations introduced] --> Flow3
Flow3[Mark MR as mergeable]
end
subgraph "Pipeline completed"
Build1[UpdateApprovalRule] --> Build2[LeverageCoverageReport]
Build1[UpdateApprovalRule] --> Build3[LeverageCoverageLogs]
Build2 --> Flow1
end
Questions
- How will we determine when the coverage has increased/decreased against the target branch?
- We will use an existing coverage report generated by GitLab CI to determine the diff between base/head pipeline
- How do we create the merge request approval rule?
- This is done by adding a new report_type in
ApprovalMergeRequestRule
as you can see on this MR
- This is done by adding a new report_type in
- Is there anything else we need to do in order to hook up the coverage rule to the merge request page?
- Nope the groupstatic analysis already build up the foundation to add our new rule out of the box
- What do we do if coverage is unavailable on the source branch? Target branch?
-
Good question, we should look into what groupstatic analysis did for Vulnerability-Check
andLicense-Check
-
Documentation
Data
Edited by Max Orefice