Connecting GitLab

GitLab support is code-complete and tested against recorded fixtures. It has not been run against a live GitLab project.

This page sits outside the install flow deliberately. Placement is a claim, and putting an untested path next to a tested one would assert a parity we have not earned.

If you are evaluating Garboard on GitLab, talk to us first: hello@winchlabs.io. We would rather be in the room for the first one.

Configuration

The webhook secret is fail-closed. Leave GARBOARD_GITLAB_WEBHOOK_SECRET unset and every delivery is refused, with a warning logged at startup. There is no unauthenticated mode: an unsigned webhook endpoint on a review gate would let anyone submit anything for review.

One host per instance. An install speaks GitHub or GitLab, not both.

A real behavioural difference

GitLab commit statuses have no neutral state.

On GitHub, an advisory-only review posts a neutral check — visibly “we looked, nothing blocking”. GitLab does not have that colour. So on GitLab an advisory posts a success status with the description prefixed advisory ·.

The information survives; the traffic light does not. If your team reads status colour rather than status text, an advisory on GitLab will look like a clean pass. Worth knowing before you wire it into a merge policy.

Tenant binding

Installations bind by root namespace. Every table is organisation-scoped, and the webhook path passes the installation’s organisation explicitly rather than falling back to a default — otherwise one tenant’s muted rules would stop applying to their own merge requests.