Commit 781c0a23 authored by Max Woolf's avatar Max Woolf Committed by Evan Read

Expand external status check documentation

Adds more information about the permissions model,
the upcoming requirement for a status parameter and
the asynchronous nature of the callback.
parent a53765b9
...@@ -46,6 +46,8 @@ GET /projects/:id/merge_requests/:merge_request_iid/status_checks ...@@ -46,6 +46,8 @@ GET /projects/:id/merge_requests/:merge_request_iid/status_checks
For a single merge request, use the API to inform GitLab that a merge request has passed a check by an external service. For a single merge request, use the API to inform GitLab that a merge request has passed a check by an external service.
Execute this API call as any user with rights to approve the merge request itself.
```plaintext ```plaintext
POST /projects/:id/merge_requests/:merge_request_iid/status_check_responses POST /projects/:id/merge_requests/:merge_request_iid/status_check_responses
``` ```
......
...@@ -28,6 +28,32 @@ You can configure merge request status checks for each individual project. These ...@@ -28,6 +28,32 @@ You can configure merge request status checks for each individual project. These
To learn more about use cases, feature discovery, and development timelines, To learn more about use cases, feature discovery, and development timelines,
see the [external status checks epic](https://gitlab.com/groups/gitlab-org/-/epics/3869). see the [external status checks epic](https://gitlab.com/groups/gitlab-org/-/epics/3869).
## Lifecycle
External status checks have an **asynchronous** workflow. Merge requests emit a merge request webhook payload to an external service whenever:
- The merge request is changed. For example, title or description.
- Code is pushed to the source branch of the merge request.
- A comment is made in the merge request discussion.
```mermaid
sequenceDiagram
Merge request->>+External service: Merge request payload
External service-->>-Merge request: Status check response
Note over External service,Merge request: Response includes SHA at HEAD
```
When the payload is received, the external service can then run any required processes before posting its response back to the merge request [using the REST API](../../../api/status_checks.md#set-status-of-an-external-status-check).
Merge requests return a `409 Conflict` error to any responses that do not refer to the current `HEAD` of the source branch. As a result, it's safe for the external service to process and respond to out-of-date commits.
External status checks have the following states:
- `pending` - The default state. No response can been received by the merge request from the external service.
- `response received` - A response from the external service has been received and approved by it.
Support for adding a `failed` state is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338827).
## View the status checks on a project ## View the status checks on a project
Within each project's settings, you can see a list of status checks added to the project: Within each project's settings, you can see a list of status checks added to the project:
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment