GitLab

Works with gitlab.com and self-managed GitLab. Each connection has its own project or group access token (scopes api, role Developer or higher) and its own webhook secret, so there is nothing to configure on the notifier beyond the shared WT_PUBLIC_URL, WT_INTERNAL_TOKEN, WT_API_INTERNAL_URL and WT_SECRET_KEY.

Install (organization admin)

The API calls POST /internal/connect/gitlab/install {org_id, user_id, base_url, token} after it checked ManageConnectors. base_url defaults to https://gitlab.com; for self-managed GitLab it must be https (an admin setting, validated on save and on every call, and every request goes through the same private-address guard as the other connectors). Watchtower checks the token with GET /api/v4/version, stores it sealed and answers once with:

• webhook_url: https://<WT_PUBLIC_URL>/connect/gitlab/webhook/<id>

• webhook_secret: shown only now; stored sealed.

In GitLab add a webhook with that URL, the secret as the Secret token and the trigger Deployment events. Then map projects with POST /internal/scm/repos {installation_id, project_id, repos: ["group/sub/name"]}.

What it does

The same as GitHub (see github.md), with GitLab's terms:

• Webhooks are accepted only with the right X-Gitlab-Token (compared in constant time, checked before the body is read); anything else is a 401. A repeated X-Gitlab-Event-UUID is ignored.

• A Deployment Hook event with status success becomes a deployment in the environment of the same name.

• Commits come from the repository compare API with each commit's diff paths (at most 250 commits and 100 files per commit). Fixes WT-<issue id> in a commit message resolves the issue in the release.

• Each merge request in the release gets one note, updated on the next deployment.

• Create an issue from an error or trace page with POST /internal/scm/issue.

Permanent deployment errors (unknown environment, lost role) are answered 202 so GitLab never disables the hook; only transient failures return 5xx. Fills back off and pause like GitHub's.