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

  1. Add a new text input field to the Add approval rule modal that accepts an endpoint --> External service URL
  2. GitLab sends a JSON Object to External service URL
  3. Customer's System parses the JSON Object and performs required tasks
  4. 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?
  5. 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
  6. 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

  1. GitLab accepts a single {{ Endpoint }} from customer within Group Settings
  2. GitLab sends a JSON Object to customer {{ Endpoint }}
  3. Customer's System parses the JSON Object and performs required external {{ Function }}
  4. If function passes, a 200 OK response is sent back to GitLab
  5. 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?
  6. Include a retry button (for expected failures from customer system or other status codes)

Next Iteration

  1. Customer can add multiple {{ Endpoint }} to Group Settings
  2. Customer can add Approval Rule to require {{ Function }} passes (200 OK response from provided endpoint)
  3. The MR approval widget contains a list of Required Approvers - External Systems
  4. If approvals are satisfied, MR can be approved.
  5. 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
clip-2020-01-22 test Modal
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.

Links

See Figma →

Edited by Austin Regnery