GitHub, GitLab, Azure DevOps, and Bitbucket Integration: Core Concepts and Mental Model

1. The practical problem: integration is a trust graph, not a token field

Chapter 17 established that a pull-request result is meaningful only when the checkout SHA, target branch, merge base, edition, analysis task, and Quality Gate are known. Chapter 18 adds a second trust boundary: how SonarQube is allowed to read provider metadata and report results back to the provider.

A common anti-pattern is to create one powerful personal token, paste it into a CI YAML file, and use it for repository access, analysis, decoration, and administration. That makes failures hard to diagnose and creates a credential with far more authority than any one action requires. A governed integration instead assigns each credential to a specific owner, direction, scope, storage location, lifetime, and revocation path.

2. Mental model: three trust paths cross the same workflow

flowchart TD
  R[Provider repository / PR] -->|checkout metadata| C[CI runner]
  C -->|SONAR_TOKEN| S[Scanner]
  S -->|analysis report| Q[SonarQube Server]
  Q -->|Compute Engine| G[Quality Gate]
  P[Provider app / technical account] -->|scoped provider credential| Q
  Q -->|provider API| D[Check / MR comment / PR status]
  W[Optional provider event / callback] -. not scanner auth .-> Q
  G --> D

The scanner credential and provider credential are different. The SonarQube analysis token authorizes report submission to SonarQube. The GitHub App, GitLab token, Azure PAT, or Bitbucket OAuth/API credential authorizes SonarQube to interact with the provider. A webhook or callback carries an event or browser redirect; it is not a substitute for either authentication path.

3. Edition and capability boundary

Community Build can still run scanners inside GitHub Actions, GitLab CI/CD, Azure Pipelines, Bitbucket Pipelines, Jenkins, or other runners. That is CI execution. It is not the same as licensed branch/PR analysis or native provider decoration.

4. State map: capture ownership before credentials

5. Four provider models: similar goal, different credentials

6. GitHub: prefer an app identity over a personal token

A GitHub App gives the integration its own identity and installation boundary. For SonarQube repository import and pull-request reporting, current Sonar guidance requires repository permissions that include Checks: read/write and Pull Requests: read/write; private repositories also require Contents: read. Metadata is read-only. Additional Administration, organization membership, email, or code-scanning-alert permissions belong only to specific optional provisioning/auth/security-alert features.

This is materially safer than a human personal token because the App can be installed on selected organizations/repositories, its permissions are explicit, and its private key/client secret can be rotated independently of a developer account.

7. GitLab: technical account or group token, scoped to the repositories

For SonarQube’s global GitLab configuration, Sonar currently documents either a personal access token from a dedicated account with at least Reporter permission or a Group Access Token, with api scope so SonarQube can import/report Quality Gate status to merge requests. For repository onboarding, the user-side import flow can use a read_api token. Preserve which token is performing which action; “GitLab token” is not enough evidence.

8. Azure DevOps: technical PAT and extension are separate pieces

Azure DevOps integration has both a SonarQube global configuration and the Azure DevOps Extension/service endpoint used in pipelines. Current Sonar guidance recommends a dedicated technical account. The PAT used for pull-request Quality Gate reporting needs Code read/write on the analyzed repositories. Azure PATs have expiry/lifecycle behavior, so expiration is part of the operating evidence—not an incidental field.

9. Bitbucket: do not freeze automation to deprecated credential names

Bitbucket Cloud is changing its authentication UI. Current Sonar documentation still contains “OAuth consumer” language in places, but Sonar staff confirmed in August 2026 that current Bitbucket Cloud uses an OAuth Client: use Client credentials, Pull requests Read permission, and map Sonar’s older OAuth Key/Secret labels to Client ID/Secret where the product UI has not caught up. Repository import uses a separate API token with read:repository:bitbucket; App passwords are deprecated.

10. Webhook, callback, outbound API, and CI authentication are different arrows

11. Read-only/non-destructive inspection first

git rev-parse HEAD
git remote -v
git branch --show-current
sonar-scanner --version
curl -fsS "$SONAR_HOST_URL/api/system/status"

# After analysis, preserve the task identity rather than assuming a provider check exists:
cat .scannerwork/report-task.txt
CE_TASK_ID="$(sed -n 's/^ceTaskId=//p' .scannerwork/report-task.txt)"
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/ce/task?id=$CE_TASK_ID"

In the provider UI, inspect app/token owner, repository installation/access, exact scopes, expiry, callback/base URL, and any current check/status/comment. Do not reveal secret values in screenshots or evidence files.

Knowledge check

Official references and version notes

• SonarQube downloads / edition matrix — current Community Build and Server editions; branch/PR analysis and provider decoration begin in Developer Edition.
• GitHub App integration — dedicated App, Checks/Pull Requests permissions, private repository Contents read, optional permissions, and webhook guidance.
• GitHub project integration — bound project and pull-request Quality Gate/check behavior.
• GitLab global integration — dedicated Reporter account or Group Access Token with API scope and stored/revocable token.
• GitLab repository import — import token read_api flow and repository binding.
• Azure DevOps integration — global configuration, technical PAT, extension/pipeline model, Quality Gate reporting and PR feedback.
• Azure repository import — project import PAT and bound-project behavior.
• Bitbucket Cloud global integration — SonarQube’s global OAuth configuration and pull-request permission model.
• Bitbucket Cloud repository import — API token with read:repository:bitbucket; App passwords deprecated.
• Sonar staff clarification on Bitbucket Cloud OAuth Client terminology (Aug–Sep 2026) — current UI uses OAuth Client / Client ID / Secret, client credentials, Pull requests Read; older maintained Sonar lines needed specific patched releases after a Bitbucket OAuth field change.
• SonarQube Web API — bearer authentication and API guidance used for local evidence queries.
• SonarScanner CLI 8.1.0.6389 — scanner baseline used by the mandatory lab.