Checkpoint Lab — Branches, Pull Requests, Merge Requests, and Edition-Aware Analysis

1. Checkpoint scenario

Your team proposes one commit on feature/demo for merge into main. Build a packet that lets a reviewer answer:

• Which exact main and feature revisions were involved?
• What is their merge base and changed-file set?
• Was the checkout shallow?
• Which SonarQube project/analysis mode was actually used?
• What branch/PR parameters would Developer+ require?
• Did scanner upload and Compute Engine complete?
• What Quality Gate state exists?
• Was provider decoration actually attempted/successful, or only simulated?

2. Exact assumptions

3. Predictions before action

Write at least these predictions before running the checkpoint:

• P1: The feature SHA has exactly one commit not on main and the merge base equals the main baseline SHA.
• P2: The Community Build feature simulation will create an independent project analysis, not a branch/PR object under the main project.
• P3: A depth-1 clone will report shallow state and may be unable to calculate the target merge base until history is restored.
• P4: A manually wrong PR base can override correct auto-detected metadata on a licensed CI path.

4. Capture the revision/build manifest

mkdir -p evidence/checkpoint

git rev-parse main > evidence/checkpoint/main-sha.txt
git rev-parse feature/demo > evidence/checkpoint/feature-sha.txt
git merge-base main feature/demo > evidence/checkpoint/merge-base.txt
git rev-list --left-right --count main...feature/demo \
  > evidence/checkpoint/ahead-behind.txt
git diff --name-status main...feature/demo \
  > evidence/checkpoint/changed-files.txt
git log --oneline --decorate --graph --all -12 \
  > evidence/checkpoint/history.txt

5. Execute and preserve the Community Build-safe analyses

Analyze main with sq-ch17-main, then the feature revision with sq-ch17-feature-sim, exactly as Lesson 2 describes. For each run preserve:

• revision SHA and shallow state;
• scanner version/runtime and effective project key;
• scanner.log and .scannerwork/report-task.txt;
• ceTaskId and terminal Compute Engine status;
• Quality Gate status and any relevant measures/issues;
• a statement that the feature simulation’s overall values are not PR New Code values.

6. Deliberate mistake: shallow clone + wrong PR base manifest

# From the lab parent directory:
rm -rf checkpoint-shallow
ORIGIN_URL="file://$(pwd)/origin.git"
git clone --depth 1 --branch feature/demo "$ORIGIN_URL" checkpoint-shallow
cd checkpoint-shallow
mkdir -p evidence/broken

git rev-parse HEAD | tee evidence/broken/feature-sha.txt
git rev-parse --is-shallow-repository | tee evidence/broken/is-shallow.txt
printf '%s\n' \
  'sonar.pullrequest.key=17' \
  'sonar.pullrequest.branch=feature/demo' \
  'sonar.pullrequest.base=develop' \
  | tee evidence/broken/pr-identity.properties

git merge-base HEAD origin/main 2>&1 \
  | tee evidence/broken/merge-base.txt || true

Preserve this failure. Do not run the wrong commercial parameters against a real provider.

7. Repair independently and verify each prediction

git fetch --unshallow origin
git fetch origin main:refs/remotes/origin/main

git rev-parse --is-shallow-repository \
  | tee evidence/is-shallow-repaired.txt
git merge-base HEAD origin/main \
  | tee evidence/merge-base-repaired.txt
git diff --name-status origin/main...HEAD \
  | tee evidence/changed-files-repaired.txt

cat > evidence/pr-identity-repaired.properties <<'EOF'
sonar.pullrequest.key=17
sonar.pullrequest.branch=feature/demo
sonar.pullrequest.base=main
EOF

Verification is independent: Git proves history/target/merge base; the corrected manifest proves intended PR identity. On an optional Developer+ CI path, a new SonarQube task proves the repaired scanner identity.

8. Optional Developer+ proof

If a licensed disposable instance and supported CI/provider are available:

1. Analyze the target main first.
2. Ensure full checkout and target ref presence.
3. Run PR analysis through CI, preferably using provider auto-detection; if manual, use the repaired PR identity exactly.
4. Preserve report-task.txt, CE task, SonarQube PR key, New Code measures/issues, and Quality Gate.
5. If the project is bound, preserve provider decoration/check state separately.

9. Required evidence packet

10. Verification checklist

• ☐ Main/feature SHAs and merge base are exact and independently reproducible.
• ☐ Shallow state is captured before and after repair.
• ☐ Project keys are stable and the simulation project is labeled as simulation.
• ☐ PR key/source/base are correct after repair.
• ☐ Community Build vs Developer+ feature availability is explicit.
• ☐ Scanner upload and Compute Engine completion are recorded separately.
• ☐ Quality Gate and CI/provider decoration are not collapsed into one status.
• ☐ No unrelated project/branch/history was deleted or rewritten.
• ☐ All disposable analysis tokens are revoked.

11. Guarded cleanup

• Revoke both Community Build project-analysis tokens and test that they no longer authenticate.
• Delete sq-ch17-main and sq-ch17-feature-sim only if you created them solely for this lab and have exported the packet.
• Delete the local author, origin.git, and shallow-clone directories only after evidence capture.
• Do not delete shared server data, global profiles/gates, external repositories, or provider integrations.

12. What Chapter 17 adds

This chapter adds SCM identity governance to the SonarQube operating model. A branch/PR result is now tied to an exact source SHA, target, merge base/history depth, edition capability, scanner identity, asynchronous task, gate, and provider-delivery state. That chain prevents “the PR was green” from becoming an unauditable statement.

Chapter 18 continues into GitHub, GitLab, Azure DevOps, and Bitbucket Integration, where provider binding, authentication, CI wiring, decoration, and merge enforcement become the primary subject.

Knowledge check

Official references and version notes

• SonarQube downloads / edition matrix — Community Build 26.9.0.129388; Server 2026 Release 4.1; 2026.1.5 LTA; branch and pull-request analysis plus PR decoration start in Developer Edition.
• Branch analysis introduction — retained branch state, New Code and Quality Gate behavior.
• Setting up branch analysis — branch-name identity, CI integration and branch-level New Code guidance.
• Pull request analysis introduction — changed code relative to the target, New Code-only gate conditions, and provider decoration boundary.
• Setting up pull request analysis — CI prerequisite and sonar.pullrequest.key/branch/base parameters.
• Checked-out code — full Git history, target refs, merge-base relevance and fetch-depth: 0.
• Quality standards and New Code — PR New Code is the code changed relative to the target branch.
• GitHub integration — CI auto-detection and PR quality-gate reporting; Chapter 18 expands provider setup.
• SonarScanner CLI 8.1.0.6389 — scanner baseline used by the mandatory lab.