Checkpoint Lab — Scanner Ecosystem: CLI, Maven, Gradle, .NET, and Build Integration

1. Checkpoint charter

Use local/private Community Build 26.9.0.129388. Reuse or recreate the two Lesson 2 fixtures: academy-sonarqube-p07-cli and academy-sonarqube-p07-maven. Mandatory scanner versions are CLI 8.1.0.6389 and Maven scanner 5.7.0.6970. Gradle 7.3.1.8318 and .NET 11.2.1.137242 are documented optional extensions, not hidden prerequisites.

2. Assumptions manifest

3. Predictions before execution

1. CLI fixture indexes its configured Python source without a compile step.
2. Maven fixture produces target/classes before analysis and scanner evidence is tied to the Maven project.
3. Each run produces a distinct report/task ID and server-side CE task.
4. Deleting Maven bytecode before the deliberate mismatch changes scanner/build-input evidence before any Quality Gate interpretation.
5. Revoking both project tokens prevents future analyses while completed project history remains.

4. Execute scanner path A

cd sonar-p07-cli
git status --short
git rev-parse HEAD > revision.txt
sonar-scanner --version | tee scanner-version.txt
read -rsp 'CLI project token: ' SONAR_TOKEN; echo
export SONAR_TOKEN SONAR_HOST_URL='http://127.0.0.1:9000'
sonar-scanner -Dsonar.host.url="$SONAR_HOST_URL" | tee scanner.log
cp .scannerwork/report-task.txt report-task.txt

Follow the exact ceTaskId to terminal status and record the final gate separately.

5. Execute scanner path B

cd ../sonar-p07-maven
git status --short
git rev-parse HEAD > revision.txt
mvn -version | tee maven-version.txt
mvn -B clean verify | tee build.log
find target/classes -type f -print | sort > classes.txt
read -rsp 'Maven project token: ' SONAR_TOKEN; echo
export SONAR_TOKEN
mvn -B org.sonarsource.scanner.maven:sonar-maven-plugin:5.7.0.6970:sonar   -Dsonar.host.url="$SONAR_HOST_URL" | tee scanner.log
find . -name report-task.txt -print

Preserve the report/task metadata wherever the scanner writes it in this build path, then follow the exact CE task and gate.

6. Deliberate mismatch and repair

Keep the Maven project, scanner version, project key, token scope, and revision constant. Remove only compiled classes after a good build, run analysis, preserve the failure, then restore compilation.

cp -a target/classes classes.good
rm -rf target/classes
mvn -B org.sonarsource.scanner.maven:sonar-maven-plugin:5.7.0.6970:sonar   -Dsonar.host.url="$SONAR_HOST_URL" | tee broken.log || true
# Repair the cause, not the policy.
mvn -B clean verify | tee rebuild.log
mvn -B org.sonarsource.scanner.maven:sonar-maven-plugin:5.7.0.6970:sonar   -Dsonar.host.url="$SONAR_HOST_URL" | tee repaired.log

Interpret the original message as a missing build-input problem. Do not “repair” it by excluding Java, changing the project key, using admin credentials, or lowering the gate.

7. Optional extension dossier

If Gradle is available, record the wrapper/Gradle version, plugin 7.3.1.8318, build tasks, class outputs, JRE mode, and task ID. If .NET is available, record SDK + scanner 11.2.1.137242 and prove begin → build → end ordering. If unavailable, write “not executed” and retain the architecture diagram; do not fabricate evidence.

8. Required evidence packet

9. Verification checklist

• Two separate project keys and project-scoped tokens were used.
• Both exact revisions are recorded and worktrees were understood.
• CLI and Maven scanner/plugin versions are recorded.
• Maven bytecode exists for the good/repaired runs.
• Every uploaded report is correlated to its own CE task.
• Gate results are recorded only after CE success.
• The deliberate mismatch evidence remains preserved.
• Tokens are revoked and raw credential values are absent from the packet.

10. Guarded cleanup and rollback

1. Revoke both project-analysis tokens and unset SONAR_TOKEN.
2. Keep scanner caches unless there is a documented cache-specific reason to remove them.
3. Delete local fixture directories only after the sanitized packet is complete.
4. If deleting SonarQube projects, verify exact project keys first and delete only the two lab projects.
5. Do not delete database/search volumes, global quality profiles/gates, or unrelated CI state.

11. What this checkpoint proves

Proves: you can choose a scanner based on build ownership, reproduce two current scanner paths, separate runtime/build/report/CE/gate state, and diagnose one build-context mismatch causally.

Does not prove: every Gradle/.NET variant, commercial security feature, PR decoration, provider integration, production CI cache, proxy/TLS topology, or monorepo strategy is configured. Those require their own later evidence.

Knowledge check

Official references and version notes

• SonarScanner CLI — build-neutral scanner usage, cache behavior, project base directory, and Docker notes.
• SonarScanner CLI 8.1.0.6389 — official release provenance.
• SonarScanner for Maven and release 5.7.0.6970.
• SonarScanner for Gradle and release 7.3.1.8318.
• SonarScanner for .NET usage and release 11.2.1.137242.
• Scanner environment general requirements and JRE auto-provisioning.
• Official scanner examples — recommended scanner choice by build ecosystem.
• Apache Maven downloads — Maven 3.9.16 is the current stable Maven baseline used in the Maven lab.