Checkpoint Lab — Marketplace, Plugins, Extension Risks, and Compatibility Management

1. Checkpoint scenario

You own a disposable SonarQube Community Build training server. A team requests a nonessential third-party plugin because it adds a capability not currently present in the built-in analyzer set. Your job is not merely to “make it appear in the UI.” You must decide whether the plugin is governable, install it only if all preflight gates pass, verify the server/capability, remove it, and prove the exact baseline returns.

2. Exact assumptions

3. Governance inventory template

server_release,plugin_key,plugin_version,artifact,sha256,source_url,source_repo,license,maintainer,last_release,compatibility_checked,plugin_api_min,dependencies_reviewed,owner,required_by,rollback_artifact,next_upgrade_action
26.9.0.129388,<key>,<version>,<jar>,<digest>,<url>,<repo>,<license>,<publisher>,<date>,2026-09-08,<manifest>,<yes/no+note>,platform-quality,<fixture>,<path>,<keep/upgrade/remove/replace>

The checkpoint fails if required provenance fields are unknown. “Marketplace” is not an acceptable value for source_repo unless it points to the actual publisher/source record.

4. Resource and credential preflight

• ☐ Docker is available and port 9026 is free.
• ☐ The container/volume names are unique to this lab.
• ☐ The chosen plugin is nonessential and explicitly compatible with 26.9 according to current evidence.
• ☐ Canonical source/release, immutable artifact URL, exact version, SHA-256/signature evidence, and license are recorded.
• ☐ A copy of the verified JAR is stored outside the extensions volume as evidence/rollback material.
• ☐ No production database, cluster, IdP, reverse proxy, CI secret, or source tree is connected.
• ☐ If a read-only API token is used, it is a disposable lab user token and will be revoked.

5. Predictions before mutation

Write predictions before installation. At minimum:

• Prediction A: copying the verified JAR changes only the extensions volume; capability is not active until the required restart succeeds.
• Prediction B: after restart, startup logs and installed-plugin inventory will show the exact key/version, while the baseline plugin set remains otherwise unchanged.
• Prediction C: removing only that JAR and restarting will return the plugin inventory and health to baseline.
• Prediction D: a deliberately wrong expected digest will block installation before the server changes.

6. Execute the lifecycle

# 1) Baseline exact image and isolated volumes.
export LAB_NAME=sq-ch26
export LAB_URL=http://localhost:9026
export SQ_IMAGE=sonarqube:26.9.0.129388-community
mkdir -p evidence/{baseline,stage,installed,rollback}

docker volume create sq-ch26-data
docker volume create sq-ch26-logs
docker volume create sq-ch26-extensions
docker run -d --name "$LAB_NAME" -p 9026:9000 \
  -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true \
  -v sq-ch26-data:/opt/sonarqube/data \
  -v sq-ch26-logs:/opt/sonarqube/logs \
  -v sq-ch26-extensions:/opt/sonarqube/extensions \
  "$SQ_IMAGE"

# 2) Preserve baseline after the server is UP.
curl -fsS "$LAB_URL/api/system/status" > evidence/baseline/status.json
docker exec "$LAB_NAME" sh -c 'ls -lah /opt/sonarqube/extensions/plugins' \
  > evidence/baseline/plugin-files.txt
docker logs "$LAB_NAME" > evidence/baseline/container.log 2>&1

# 3) Download the exact current compatible plugin selected in preflight.
curl -fL "$PLUGIN_URL" -o "evidence/stage/$PLUGIN_JAR"
ACTUAL_SHA256="$(sha256sum "evidence/stage/$PLUGIN_JAR" | awk '{print $1}')"
test "$ACTUAL_SHA256" = "$EXPECTED_SHA256"
unzip -p "evidence/stage/$PLUGIN_JAR" META-INF/MANIFEST.MF \
  > evidence/stage/manifest.txt
cp "evidence/stage/$PLUGIN_JAR" "evidence/rollback/$PLUGIN_JAR"

# 4) Install only after gates pass; restart exactly once because plugin lifecycle requires it.
docker cp "evidence/stage/$PLUGIN_JAR" \
  "$LAB_NAME:/opt/sonarqube/extensions/plugins/$PLUGIN_JAR"
docker restart "$LAB_NAME"
curl -fsS "$LAB_URL/api/system/status" > evidence/installed/status.json
docker logs "$LAB_NAME" > evidence/installed/container.log 2>&1

# 5) Remove only the introduced artifact; restart and prove baseline recovery.
docker exec "$LAB_NAME" rm -f "/opt/sonarqube/extensions/plugins/$PLUGIN_JAR"
docker restart "$LAB_NAME"
curl -fsS "$LAB_URL/api/system/status" > evidence/rollback/status.json
docker exec "$LAB_NAME" sh -c 'ls -lah /opt/sonarqube/extensions/plugins' \
  > evidence/rollback/plugin-files.txt
docker logs "$LAB_NAME" > evidence/rollback/container.log 2>&1

7. Optional analyzer smoke scan

If the selected plugin is scanner/analyzer-side, a clean web startup is necessary but not sufficient. Use a tiny synthetic repository appropriate to that plugin’s language and preserve the ordinary analysis chain:

git rev-parse HEAD > evidence/installed/fixture-revision.txt
sonar-scanner -X 2>&1 | tee evidence/installed/scanner.log
cp .scannerwork/report-task.txt evidence/installed/report-task.txt
CE_TASK_ID="$(sed -n 's/^ceTaskId=//p' .scannerwork/report-task.txt)"
printf '%s\n' "$CE_TASK_ID" > evidence/installed/ceTaskId.txt
curl -fsS -H "Authorization: Bearer $SONAR_API_TOKEN" \
  "$LAB_URL/api/ce/task?id=$CE_TASK_ID" \
  > evidence/installed/ce-task.json

Scanner success, report upload, ceTaskId/Compute Engine completion, resulting measures/issues, gate state, and CI status remain separate facts. The plugin’s existence does not collapse these states.

8. Verification checklist

• ☐ Exact Community Build image/release and baseline plugin inventory are preserved.
• ☐ Plugin key/version/source/repository/license/digest and compatibility evidence are complete.
• ☐ Deliberate bad-digest check failed before installation and its evidence was retained.
• ☐ Only the verified JAR was copied into the isolated extensions volume.
• ☐ Server returned to UP after the required install restart.
• ☐ Startup logs identify the exact plugin or otherwise prove the expected loading state.
• ☐ If scanner-side, a synthetic fixture independently verifies analyzer behavior and preserves ceTaskId.
• ☐ Plugin removal changed only the introduced JAR.
• ☐ Server returned to baseline health and plugin inventory after rollback.
• ☐ Upgrade decision record says what happens to this plugin on the next SonarQube release.

9. Required evidence packet

10. Cleanup and rollback

# Only after rollback evidence is complete:
docker rm -f sq-ch26
docker volume rm sq-ch26-data sq-ch26-logs sq-ch26-extensions
unset SONAR_API_TOKEN PLUGIN_URL PLUGIN_JAR PLUGIN_KEY PLUGIN_VERSION EXPECTED_SHA256

If a plugin caused the server not to start, the rollback is not “delete the evidence and rebuild everything.” Remove only the introduced artifact, restart the isolated server, and prove baseline recovery. In a real governed environment, use the approved maintenance/backup procedure rather than improvising direct database/search edits.

11. What Chapter 26 adds to the operating model

The governed SonarQube model now includes executable extension inventory as first-class configuration: every plugin has provenance, exact bytes, compatibility, license/dependency ownership, startup evidence, a rollback artifact, and a next-upgrade decision. Platform availability is no longer assumed to survive arbitrary JAR changes.

Chapter 27 continues naturally into Server Logs, Monitoring, Health, Elasticsearch, and Operational Diagnostics, where the startup and runtime evidence used here becomes a broader observability and incident-diagnosis discipline.

Knowledge check

Official references and version notes

• Community Build — Installing a plugin — Marketplace/manual paths, compatible JAR requirement, extensions/plugins, Docker/Kubernetes guidance, restart and uninstall behavior.
• Community Build — Using Marketplace — installed/compatible plugin discovery, internet/proxy behavior, Administer System requirement, pending install/update/uninstall and restart.
• Community Build — Plugin version matrix — current plugin-to-Community-Build compatibility table.
• Community Build — Plugin basics — Plugin API, scanner/Compute Engine/web extension points, manifest metadata, dependencies and Plugin-RequiredForLanguages.
• Community Build — Performing the update — install compatible third-party plugins for the target release instead of blindly copying old plugin folders.
• SonarQube Server — Installing a plugin — current commercial manual-install model and Data Center application-node consistency/maintenance rules.
• Sonar Plugin API repository — independent Plugin API release stream and SonarQube ↔ Plugin API compatibility mappings.
• Official SonarQube Docker image tags — exact 26.9.0.129388-community image used by the checkpoint.