Skip to content
Exlogare
Exlogare / Documentation

GitLab and Bitbucket webhook mode

Event-driven integration for environments where OAuth is not allowed.

Webhook mode is the right choice when OAuth is not desirable or is blocked by your security policy.

How it works

  1. You register one webhook on the project or the group.
  2. GitLab ships Pipeline events and Job events to https://api.exlogare.net/webhook/gitlab.
  3. Exlogare verifies the shared secret (via the X-Gitlab-Token header) and enqueues the pipeline.
  4. On failure, Exlogare asynchronously fetches logs through the GitLab API and runs the RCA. The log text is processed in memory and discarded — only the generated analysis and minimal routing metadata are persisted.

Setup

The fastest path is through the Exlogare dashboard:

  1. Open Integrations → GitLab → New webhook.
  2. Copy the URL and the secret the wizard shows you.
  3. In GitLab: Settings → Webhooks on the project (or Group → Hooks for the whole group).
  4. Paste the URL, put the secret into Secret token, tick Pipeline events and Job events.
  5. Save — GitLab sends a test ping right away.

If you connect the project via OAuth, or hand a Personal Access Token (PAT) to the wizard, the webhook is registered for you — you can skip steps 3–5.

Which events to enable

  • Pipeline events — the source of truth for the failure itself and the pipeline URL.
  • Job events — required for the exact failing job link and log retrieval.

You do not need to enable Merge Request events, Push events, or other types — they would only add noise on the GitLab side.

Verifying delivery

GitLab’s webhook page has a Recent deliveries panel: you can inspect statuses, headers and response bodies there. A healthy call returns 202 Accepted. A 404 typically means the project is not attached to a connector in Exlogare — open Integrations → GitLab and make sure the project is in the active list.

Bitbucket Data Center / Server (webhook-only) {#bitbucket-dc}

Bitbucket Data Center / Server doesn’t expose OAuth in Exlogare, so it always lives in webhook mode. The shape mirrors the GitLab flow:

  1. Open Integrations → Bitbucket → New connection and choose Self-hosted. Provide the base URL, project key and repo slug — the wizard returns a webhook URL (https://api.exlogare.net/webhook/bitbucket) and a freshly-generated shared secret.
  2. In Bitbucket: Repository settings → Webhooks → Create webhook. Paste the URL into URL, the secret into Secret, tick Repository events → Build status updated, leave Active on, and Save.
  3. Bitbucket signs the body with HMAC-SHA256 in X-Hub-Signature: sha256=…. Exlogare verifies the signature, parses the repo:build_status_updated event, and queues the failing run for analysis. Healthy deliveries return 202 Accepted.

The repo:build_status_updated event is what your external CI (Jenkins / Bamboo / TeamCity) triggers indirectly when it publishes a build status to Bitbucket through the Build Status REST API. The pipeline URL in the comment points at that external CI’s job page (we don’t fetch DC-side logs ourselves).

DC < 7.4 does not ship the Build status updated event. Either upgrade DC to 7.4+ or use the manual POST /api/analyze endpoint as a workaround.

If you have a Personal Access Token handy with Project admin rights, paste it into the wizard and we will create the webhook for you via the DC REST API. Otherwise the manual checklist above is the way.

Bitbucket Cloud webhook-only {#bitbucket-cloud}

Bitbucket Cloud also supports webhook-only operation, although OAuth is more convenient. The setup is the same as DC except:

  • The webhook event is repo:commit_status_updated (instead of repo:build_status_updated).
  • You register the webhook under Repository settings → Webhooks in Bitbucket Cloud.
  • HMAC verification still uses X-Hub-Signature (SHA-256).