Auto-close bugs via commit message (GitHub & GitLab)

If you already mark PRs with Fixes JIRA-1234 to close issues in your tracker of choice, ClickProbe supports the same idiom. Push a commit whose message contains Fixes CP-<n> (or Closes / Resolves), and the referenced bug auto-resolves.

No IDE plugin changes. No MCP calls. Just a webhook URL pasted into your repo settings.

Heads up: Want bugs to close when your coding agent explicitly calls the MCP tool? See Resolve bugs from your IDE — the active (agent-driven) path.

Provision a webhook in ClickProbe

1. Sign into the control-center.
2. Go to Settings → Connect Git.
3. Click Add webhook, pick your provider (GitHub or GitLab), give the webhook a label (e.g. acme/prod), and click Create.
4. The modal shows a Webhook URL and a Secret. Copy the secret immediately — it is shown only once. If you lose it, return to the list and click Rotate on that row.

Paste into GitHub

1. Your repo → Settings → Webhooks → Add webhook.
2. Payload URL: paste the URL from ClickProbe.
3. Content type: application/json — required.
4. Secret: paste the secret.
5. Which events: select “Just the push event” (avoid “Send me everything” — the receiver returns 422 for non-push events).
6. Check Active. Save.

GitHub sends a ping event on save — that’s normal; the receiver responds 422 and GitHub shows it as a failed ❌ ping delivery. This is expected behaviour: the first real push will show a green ✅.

Paste into GitLab

1. Your project → Settings → Webhooks.
2. URL: paste the URL from ClickProbe.
3. Secret token: paste the secret (GitLab uses a plain token, not HMAC — ClickProbe handles both automatically).
4. Trigger: check Push events. Uncheck all others.
5. Enable SSL verification: keep on (production).
6. Add webhook.

Trigger an auto-close

Push a commit whose message contains one of these patterns (case-insensitive). Both the CP-<n> and #<n> formats are accepted:

Multiple IDs per commit are supported — a squash commit with Fixes CP-1, CP-2, CP-3 closes all three.

The referenced bug transitions to resolved within a couple of seconds. The dashboard audit log shows the close was triggered by your GitHub or GitLab webhook, with the commit’s short SHA.

What happens when the bug is still new

ClickProbe’s FSM normally requires new → confirmed → resolved. The webhook receiver auto-confirms first when it sees a commit referencing a new-status bug, on the reasoning that the commit itself is proof the developer triaged it. Two audit rows appear: one new → confirmed, one confirmed → resolved, both attributed to the webhook bridge.

If you prefer strict mode (webhook closes only pre-confirmed bugs), ask the operator to set CLICKPROBE_WEBHOOK_AUTO_CONFIRM=false.

See Bug Inbox → Resolve for the customer-facing status lifecycle.

Rate limit

Each webhook is capped at 60 deliveries per minute. A 61st delivery in the same minute returns HTTP 429 with a Retry-After header (integer seconds). GitHub and GitLab both honour Retry-After and will re-deliver automatically.

A single delivery can close many bugs — the 60/min cap is on deliveries, not on closures. A merge-train squash commit with 30 Fixes CP-<n> references counts as one delivery.

What does NOT auto-close

• git revert / Reopens CP-<n>: not handled in v1. A revert leaves the bug resolved. Manually reopen via the dashboard or an MCP call if needed.
• Bitbucket: not supported yet. Contact support if you need it.
• PR events (open, review, merge): not handled. The receiver acts on push only. Merging a PR typically fires a push to the default branch; that push is what triggers the close.

Troubleshooting

See troubleshooting.md — Webhook auto-close.

Related

• Resolve bugs from your IDE — the explicit MCP write path (clickprobe.resolve_bug).
• Settings → Connect Git — manage your incoming webhooks.