GitLab merge request checks

Connect a GitLab project so every merge request runs your test plans and reports back as a commit status — no GitLab App to install, no admin approval needed beyond a token you create yourself.

Connect a project

1. In GitLab, create a project access token (or a group access token) under Settings → Access tokens, with the api scope.
2. In Bugmole, open Settings → GitLab checks (in your account menu), choose the project, and enter the GitLab project path (group/project) and the token. For self-managed GitLab, also set GitLab host (it defaults to gitlab.com).
3. Bugmole confirms it can reach the project, then shows you a webhook URL and a one-time secret.
4. In GitLab, open Settings → Webhooks, add a webhook with that URL and secret token, and enable the Merge request events trigger.

The token is stored encrypted and is only ever used by Bugmole to post commit statuses back to that project.

What runs, and when

Opening or reopening a merge request, or pushing a new commit to one, starts the plans you chose (or every plan, by default). Editing a title, description or labels doesn't start a run.

Each run reports a commit status named Bugmole: <plan> on the merge request's latest commit — pending while queued, running while it executes, then success, failed or canceled, with a link back to the run in Bugmole.

Where it runs

Choose Bugmole Cloud (for projects on Bugmole storage) or My workers, and optionally a preview-URL template using {number} (the merge request's IID), {branch}, {sha} or {short_sha} — or point it at one of the project's environments instead.

Managing a connection

• Rotate webhook secret issues a new secret if the old one leaks; update the value in GitLab's webhook settings afterward.
• Pause stops starting new runs without deleting the connection.
• Remove deletes it; the webhook in GitLab keeps sending requests, which Bugmole will then reject as unknown.

This is included on Team and above.