GitLab CI adapter
Reference for the GitLab CI adapter. Webhook events, verification, status mapping and limits.
The GitLab adapter turns GitLab webhook events into Prodgator runs, jobs and deployments. To set it up, see Connect GitLab. Only gitlab.com is supported.
Events
| GitLab event () | Prodgator record |
|---|---|
| Pipeline Hook | Pipeline run; also wakes the merge request gate of the commit |
| Job Hook | Job (stage) of a run; a finished job wakes the merge request gate of the commit |
| Deployment Hook | Deployment |
| Merge Request Hook | Merge request gate (see Pull request gates on GitLab) and SPACE metrics; actions , , , , , , , and |
| Push Hook | Policy sync from the repository, only for a push to the default branch that changes |
Other events (Tag Push Hook, Release Hook, Note Hook and the rest), other merge request actions and other pushes are acknowledged and dropped.
Compared with GitHub
| GitHub event | GitLab event | |
|---|---|---|
| Pipeline Hook | Same records | |
| Job Hook | Same records | |
| , | Deployment Hook | Same records; a deployment waits for approval |
| None | GitLab has no external deployment rule; Prodgator approves protected environments through the API instead | |
| , | Merge Request Hook | Gates and SPACE metrics. GitLab approvals count as reviews; review comments are not read |
| , , | Pipeline Hook, Job Hook | Wake the merge request gate when the commit's pipeline or a job finishes |
| Pipeline Hook | Merge train pipelines are merge request pipelines | |
| Push Hook | Policy sync from the repository | |
| Dependabot, code scanning and secret scanning alerts | None used | GitLab findings come from uploaded reports |
| , (tags) | Release Hook, Tag Push Hook | Not used on either provider |
Webhook verification
Each connection has its own webhook URL, , and its own secret token. GitLab sends the token in the header. Prodgator compares it with the connection's stored token and answers if it does not match.
Status mapping
| GitLab status | Prodgator status | Pipelines tab |
|---|---|---|
| , , , , | Queued | |
| Running | ||
| Awaiting approval | ||
| Success | ||
| Failed | ||
| Cancelled | ||
| Cancelled |
Field mapping
| GitLab field | Prodgator field |
|---|---|
| Run ID | |
| Branch | |
| Commit | |
| Duration | |
| , else | Release name |
| (Deployment Hook) | Release name of the deployment |
| Repository | |
| Actor | |
| Job name | |
| Job status |
Deployments
Every Deployment Hook is recorded, for any environment. A deployment to an unprotected environment is marked Not gated.
Protected environment approvals are sent with the approver's own linked GitLab account, because GitLab records the token's owner as the approver. See Approve deployments.
Re-run a job
and above can re-run one finished job from its row. Prodgator calls with the connection's token, never a person's linked account. A retried manual job waits as manual; Prodgator does not start it.
Logs
Prodgator reads job logs through the GitLab API with the connection's token.
Limits
- Self-managed GitLab is not supported.
- Merge request pipelines show the source branch.
- Parent and child pipelines show as separate runs.
- If GitLab only allowed per-project webhooks (no Premium), projects added to the group later are not covered. Reconnect the group to add them.
- Policy files in a GitLab project bind its deployment environments by environment name only; a in a binding is ignored, since GitLab deployments name no workflow.
- GitLab lists at most 20 commits in a Push Hook. A push with more is treated as changing the policy folder, and Prodgator reads the default branch to find out.