Checkpoint Lab — GitHub, GitLab, Azure DevOps, and Bitbucket Integration

1. Checkpoint scenario

You are designing SonarQube integration for four teams that use GitHub, GitLab, Azure DevOps, and Bitbucket Cloud. Production credentials do not exist yet. Your deliverable must contain:

1. a least-privilege provider-integration design for all four platforms;
2. one real local SonarQube analysis using sq-ch18-provider-lab;
3. one local GitHub-style decoration simulation driven by the real Quality Gate;
4. one deliberate provider-scope failure and repair;
5. an optional Developer+ sandbox procedure, or an explicit unexecuted limitation;
6. credential/revocation and cleanup evidence.

2. Exact version/edition assumptions

3. Provider integration design dossier

Create provider-design.md with one row per provider:

Also record Server base URL/callback expectations and whether provider webhooks are actually required. Do not invent a webhook merely because the provider supports them.

4. Predictions before execution

• Prediction A: the real Community Build scanner run will create a ceTaskId; after CE success, the project will have a queryable Quality Gate state.
• Prediction B: changing only simulated provider checks permission from read_write to read will not change SonarQube analysis/gate evidence, but the provider simulator will fail.
• Prediction C: restoring the permission contract will produce a local simulated provider check whose conclusion maps to the real gate.
• Prediction D: no native PR decoration will exist on Community Build; the packet must say so explicitly.

5. Execute the analysis and preserve the asynchronous chain

export SONAR_HOST_URL="http://localhost:9000"
export SONAR_PROJECT_KEY="sq-ch18-provider-lab"
mkdir -p evidence/checkpoint/sonar evidence/checkpoint/provider

git rev-parse HEAD | tee evidence/checkpoint/sonar/revision.txt
sonar-scanner -X 2>&1 | tee evidence/checkpoint/sonar/scanner.log
cp .scannerwork/report-task.txt evidence/checkpoint/sonar/report-task.txt

CE_TASK_ID="$(sed -n 's/^ceTaskId=//p' .scannerwork/report-task.txt)"
echo "$CE_TASK_ID" | tee evidence/checkpoint/sonar/ce-task-id.txt

curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/ce/task?id=$CE_TASK_ID" \
  | tee evidence/checkpoint/sonar/ce-task.json

curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/qualitygates/project_status?projectKey=$SONAR_PROJECT_KEY" \
  | tee evidence/checkpoint/sonar/gate.json

Do not continue until CE is terminal. Scanner exit, upload, CE, analysis completion, gate, CI job, and provider decoration remain separate states.

6. Simulated binding, failure, and repair

Reuse Lesson 2’s binding.json and provider_sim.py, but copy them into evidence/checkpoint/provider/. Run three steps:

1. Good contract: Checks RW + Pull Requests RW → provider check generated.
2. Broken contract: Checks Read only → preserve SIMULATED_PROVIDER_403.
3. Repair: restore only Checks RW → regenerate provider check.

Hash the relevant evidence to prove the SonarQube gate did not change during provider-only failure/repair:

sha256sum evidence/checkpoint/sonar/revision.txt \
  evidence/checkpoint/sonar/report-task.txt \
  evidence/checkpoint/sonar/gate.json \
  | tee evidence/checkpoint/sonar/evidence.sha256

7. Optional real Developer+ sandbox flow

If an authorized sandbox exists, choose one provider—not all four. Create the minimum provider identity, bind/import the disposable repository, run a PR/MR analysis in supported CI, and preserve:

• provider organization/repository ID;
• app/token identity and scopes with values redacted;
• SonarQube binding/configuration name;
• commit SHA, PR/MR key and target;
• ceTaskId and CE status;
• Quality Gate;
• provider check/comment/status ID and timestamp;
• credential revocation/uninstall audit evidence.

8. Required evidence packet

9. Verification checklist

• ☐ Exact source SHA is recorded.
• ☐ Scanner/server versions and ceTaskId are recorded.
• ☐ Gate was queried only after Compute Engine success.
• ☐ Provider identities/scopes differ appropriately across GitHub/GitLab/Azure/Bitbucket.
• ☐ No provider credential value exists in the packet.
• ☐ Deliberate provider failure leaves SonarQube analysis/gate evidence unchanged.
• ☐ Repair changes only the required provider permission contract.
• ☐ Native decoration is labeled Developer+ and not attributed to Community Build.
• ☐ Bitbucket’s current OAuth Client/API-token transition is documented.
• ☐ SonarQube project token is revoked and revocation verified.

10. Cleanup and rollback

• Revoke the disposable SonarQube project-analysis token and verify a read requiring that token fails.
• Delete the disposable local SonarQube project only after exporting the packet and only if you created it solely for this checkpoint.
• The mandatory provider path created no real provider credentials; record that explicitly.
• If the optional sandbox path was executed, revoke/uninstall its app/token/client after evidence capture.
• Do not delete shared provider apps, organization integrations, global SonarQube configurations, unrelated CI service endpoints, or source repositories.

11. What Chapter 18 adds to the operating model

Chapter 18 adds provider trust governance: each provider result can now be traced from repository/PR identity through a dedicated integration credential and SonarQube binding to a specific analysis task, Quality Gate, provider check, audit record, and revocation path. “The integration works” is no longer sufficient; the identity and permission boundary are evidence.

Chapter 19 continues into CI Integration with GitHub Actions, GitLab CI, Jenkins, and Other Runners, where checkout depth, runner caches, secret injection, scanner invocation, gate enforcement, and job-status behavior become the primary operational focus.

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.