GitLab, GitHub and Bitbucket OAuth

OAuth is the right fit when you want short-lived tokens, automatic project discovery, and central management without per-project webhook wiring. Exlogare supports the same high-level flow for GitLab, GitHub Actions and Bitbucket Cloud; the steps below start with GitLab, then GitHub, then Bitbucket.

When to use OAuth

• You want a single click to connect and have webhooks set up on every project automatically.
• You want to see the tenant’s project list in the Exlogare UI instead of typing paths by hand.
• Your security policy does not allow wide-scope PATs.

Register an OAuth application (self-hosted GitLab)

1. In GitLab: Admin Area → Applications → New application (or Group → Settings → Applications for a group app).
2. Redirect URI: https://api.exlogare.net/auth/gitlab/callback.
3. Scopes: api, read_user, read_api.
4. Save the application. Copy the Application ID and Secret — you’ll need them in the Exlogare wizard.

Connect from the dashboard

1. Integrations → GitLab → New OAuth connection.
2. Supply the base URL of your GitLab, the Application ID, and the Secret.
3. Click Connect and approve in GitLab.

Once approved, Exlogare walks your projects, subscribes a webhook to Pipeline events and Job events, and starts listening for failures. On plans that support Hybrid mode, a 60-second background poll kicks in as well — a safety net for dropped webhook deliveries.

gitlab.com fallback

If you are connecting gitlab.com, you do not need to register an OAuth application — Exlogare uses a platform application. Just click Connect with gitlab.com in the wizard and approve the access prompt.

Revoking access

You can revoke any OAuth token from Integrations → GitLab → Connections → Disconnect. Once revoked, the webhooks Exlogare registered through OAuth stay in GitLab — remove them by hand if you do not plan to come back.

GitHub {#github}

For GitHub Actions, create an OAuth App (or the equivalent in GitHub Enterprise):

1. Callback URL (Authorization callback): must match the URL Exlogare shows in the UI — typically https://<your-api-host>/api/integrations/github/oauth/callback (same value as the server github_oauth_redirect_uri).
2. Scopes: enable access to the repositories you want to analyse. Private repos usually need the repo scope; public-only setups may work with reduced scopes depending on your policy. Include read:user (or equivalent) so we can show the connected account in the UI.
3. Copy Client ID and generate a Client secret. For self-hosted GitHub Enterprise, open Integrations → GitHub, choose your enterprise base URL, and paste these into the self-hosted connect flow; for github.com the platform operator may have already configured a single OAuth app.

After you authorize, Exlogare subscribes to workflow_run (and check_run where applicable) for each selected repository, validates inbound deliveries with a per-hook secret (X-Hub-Signature-256), and reuses the same analysis and feedback path as GitLab (comments on the PR, then commit, then issue — according to your feedback policy).

You can disconnect from Integrations → GitHub → Connections; remove leftover repository webhooks in GitHub if you no longer need them.

Bitbucket {#bitbucket}

Bitbucket has two distinct flavours and Exlogare treats them differently:

• Bitbucket Cloud (bitbucket.org) — three-legged OAuth via Atlassian, the same UX as GitHub: pick repos, we register the webhook for you.
• Bitbucket Data Center / Server — webhook-only mode. There is no OAuth path. The “Connect” button returns a webhook URL and shared secret instead, plus an optional PAT field that lets the wizard register the hook on your behalf.

Bitbucket Cloud OAuth setup

1. In Bitbucket: Workspace settings → OAuth consumers → Add consumer.
2. Callback URL must match the one Exlogare shows in the UI — typically https://<your-api-host>/api/integrations/bitbucket/oauth/callback (the value of the bitbucket_oauth_redirect_uri setting).
3. Permissions / Scopes — tick all of the following before saving, otherwise Bitbucket rejects the authorization with error=invalid_scope:
   • Account: Read
   • Workspace membership: Read
   • Projects: Read
   • Repositories: Read
   • Pull requests: Read, Write
   • Webhooks: Read and write
   • Pipelines: Read
4. Save the consumer. Copy Key (= Client ID) and Secret (= Client secret).
5. In Exlogare open Integrations → Bitbucket → New OAuth connection, choose Cloud, paste the Key and Secret, then click Connect. Approve the access prompt in Atlassian.

For installations where the operator pre-configured platform credentials, you can skip the consumer registration entirely — the Connect button uses the platform OAuth app and the per-tenant Key / Secret fields are hidden.

After authorization Exlogare lists your workspaces, registers a repo:commit_status_updated webhook on every selected repository, and runs the standard RCA pipeline. Modes (webhook / OAuth polling / hybrid) follow the same plan matrix as GitLab and GitHub.

Bitbucket Data Center / Server (webhook-only)

1. In Exlogare open Integrations → Bitbucket → New connection, choose Self-hosted.
2. Paste the base URL of your DC instance (e.g. https://bitbucket.example.com), the project key, and the repository slug.
3. (Optional) Paste a Personal Access Token with Project admin rights; the wizard then registers the webhook for you. Otherwise we return a URL and a freshly generated secret you can paste manually.
4. In Bitbucket: Repository settings → Webhooks → Create webhook. Name Exlogare RCA, the URL and secret from the wizard, Repository events → Build status updated, Active, Save.

DC < 7.4 caveat: the Build status updated event is only available from Bitbucket Data Center 7.4 onwards. On older releases, upgrade your DC instance, or use the manual POST /api/analyze ingestion path described in the API reference.

For both flavours, you can revoke from Integrations → Bitbucket → Connections. Once revoked, leftover webhooks stay in Bitbucket — remove them by hand if you do not plan to come back.