Discovery: Allow MRs to poll external services as a criteria for approval
Problem to Solve
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 requirement for MR approvals. This creates a disjointed experience for MRs in complex compliance environments and requires additional work by our customers to stitch this data together.
Additional Information
Allowing customers to incorporate external system data into the GitLab MR creates a convenient single source of truth for the specific change being reviewed. Customers could build workflows and decision logic into the MR that leverages their existing, custom tooling or services.
Proposal
- Add a new text input field to the
Add approval rule
modal that accepts an endpoint -->External service URL
- GitLab sends a JSON Object to
External service URL
- Customer's
System
parses theJSON Object
and performs required tasks - The response to GitLab should contain necessary data such as:
pass/fail
(HTTP 200 or 400?), auth token, group id, project id, MR id or perhaps a unique hash for that specific MR payload to simplify the response query? - If GitLab receives a
200 OK
response, provide a✅ in the MR for this approval rule- This approval rule should be non-blocking in this MVC
- Include a
retry
button (for expected failures from customer system or other status codes)
Original Proposal
If the successful response is not received, the MR should be approve-able. This proposal's workflow could be:MVC
- GitLab accepts a single
{{ Endpoint }}
from customer withinGroup Settings
- GitLab sends a JSON Object to customer
{{ Endpoint }}
- Customer's
System
parses theJSON Object
and performs required external{{ Function }}
- If
function
passes, a200 OK
response is sent back to GitLab - The response to GitLab should contain necessary data such as:
pass/fail
(HTTP 200 or 400?), auth token, group id, project id, MR id or perhaps a unique hash for that specific MR payload to simplify the response query? - Include a
retry
button (for expected failures from customer system or other status codes)
Next Iteration
- Customer can add multiple
{{ Endpoint }}
toGroup Settings
- Customer can add
Approval Rule
to require{{ Function }}
passes (200 OK
response from provided endpoint) - The MR approval widget contains a list of
Required Approvers - External Systems
- If approvals are satisfied, MR can be approved.
- If approvals are not satisfied, GitLab should re-poll or listen for additional responses from a customer's
System
until approvals are satisfied
Next Iteration
- Provide multiple endpoints
- Support Approval Rules based on responses
Workflow Draft | Mockup of MR screen | Modal popup for settings |
---|---|---|
The current workflow illustrated in a Mural board. | WIP with @dmoraBerlin to design prototypes based on this workflow. | Feedback needed see comments. |
Documentation
We'll need to add documentation to include an example JSON Object
for this MR payload so customers know what data to expect for parsing and processing.
Documentation should also included the GitLab API endpoint to submit a response to (200 OK
or 400 BAD REQUEST
) and the data expected with each query.