Introduce concept of Merge Request Violation
Why are we doing this work
To implement the next iteration of the "Compliance Dashboard" we should store compliance violations such as a failure of separations of duties.
Currently this information is generated on-the-fly but this proposal is to create a new domain model: MergeRequests::ComplianceViolation
which encapsulates information about a single failure of an MR to adhere to a particular hard-coded rule.
Examples of these include:
- When an author approves their own MR.
- When a committer approves their own MR.
- When an MR is merged with an
X%
drop of code coverage.
We should implement the following:
- The new domain model as above.
- Implementation of the new violation objects when an MR is merged.
- A GraphQL implementation to allow the group-level querying of data for a group's merge requests.
Implementation plan
-
backend - Introduce new domain model - !74290 (merged) : workflowin review -
backend - On MR merge, save a list of MR violations that occured at the point of merging. -
backend - Add GraphQL type MergeRequestComplianceViolationType
available as a traversal fromMergeRequest
(maybe?).
Proposed Data Structure
-
MergeRequest
has zero or moreMergeRequests::ComplianceViolation
- Before merging, a
MergeRequest
should have NO violations.
Column Name | Type | Example | Notes |
---|---|---|---|
merge_request_id |
bigint (foreign key on merge_requests.id ) |
1 |
Which MR? |
violating_user_id |
bigint | (foreign key on users.id ) |
1 |
reason |
enum |
approved_by_author: 0 , approved_by_committer: 1 , approved_by_insufficient_users: 2
|
What caused the violation? We can map each of these to a hard-coded severity as defined by us. |
Edited by Robert Hunt