Checkpoint Lab — Quality Gates, Conditions, Policies, and Pipeline Enforcement

1. Checkpoint objective and acceptance criteria

Build an edition-aware quality-gate dossier that a reviewer can reconstruct without access to your shell history. You will prove one passing run, one failing run, the exact gate definition shared by both, the Compute Engine task behind each result, and the behavior of CI-style gate enforcement.

2. Record assumptions before touching policy

Date: 2026-09-07
SonarQube: Community Build 26.9.0.129388
Scanner: SonarScanner CLI 8.1.0.6389
Project: academy-sq-ch11
Gate: Academy Ch11 Coverage Gate
Condition: overall Coverage < 80.0% => fail
Token: project-analysis token; value never recorded
Commercial features: none required
CI/provider integration: none required; scanner wait simulates enforcement
Database/plugin/identity assumptions: inherited local lab server; no third-party plugin or IdP required

If your actual versions differ, replace these assumptions with observed values and re-check current documentation before executing the commands.

3. Preflight and guarded resources

• Confirm SONAR_HOST_URL resolves only to your authorized lab instance.
• Confirm the project/gate names are disposable and not used by other teams.
• Confirm the gate is not the instance default.
• Confirm your analysis token is project-scoped and can be revoked after the lab.
• Confirm enough disk/memory exists for the already-running local SonarQube instance.
• Create evidence/ outside any resource that a cleanup command will delete.

4. Write predictions before Run A and Run B

5. Execute the two-run experiment

Use the exact fixture and gate workflow from Lesson 2. Do not improvise new thresholds midway. For each run:

1. Save revision SHA and sonar-project.properties.
2. Generate and preserve coverage.xml.
3. Run the scanner and preserve the full log.
4. Copy .scannerwork/report-task.txt immediately.
5. Extract and record ceTaskId.
6. Wait for the matching CE task; record status/error if any.
7. Record project coverage measure and gate result with failed-condition details.
8. Record the project’s gate assignment and the gate definition again, proving policy did not change between runs.

6. Prove enforcement is a separate system state

At the failing revision, collect two CI-style outcomes:

# A. Default asynchronous behavior
set +e
sonar-scanner -Dsonar.host.url="$SONAR_HOST_URL" -Dsonar.token="$SONAR_TOKEN"
DEFAULT_RC=$?
set -e

# B. Explicit scanner-side gate enforcement
set +e
sonar-scanner \
  -Dsonar.host.url="$SONAR_HOST_URL" \
  -Dsonar.token="$SONAR_TOKEN" \
  -Dsonar.qualitygate.wait=true \
  -Dsonar.qualitygate.timeout=300
WAIT_RC=$?
set -e

printf 'default_rc=%s\nwait_rc=%s\n' "$DEFAULT_RC" "$WAIT_RC" \
  | tee evidence/ci-enforcement.txt

The packet must explain why these statuses can differ. If your CI/provider has a native SonarQube quality check, document that as the preferred production integration and keep this scanner-wait path as a local/free demonstration.

7. Required evidence packet

evidence/
├── assumptions.txt
├── gate-definition-before.json-or.md
├── project-gate-assignment.txt
├── pass-revision.txt
├── pass-coverage.xml
├── pass-scanner.log
├── pass-report-task.txt
├── pass-ce.json
├── pass-gate.json
├── fail-revision.txt
├── fail-coverage.xml
├── fail-scanner.log
├── fail-report-task.txt
├── fail-ce.json
├── fail-gate.json
├── ci-enforcement.txt
├── gate-definition-after.json-or.md
├── policy-change-record-template.md
└── cleanup-and-token-revocation.txt

Redact secrets. A token name/scope may be evidence; its value is not.

8. Write a policy-change record even though you are not changing production policy

Create a template that future operators can use:

Change ID:
Gate / projects affected:
Current condition(s):
Proposed condition(s):
Risk or business reason:
Why code remediation is insufficient:
Representative projects tested:
Predicted pass/fail changes:
Small-change and new-code implications:
Edition / metric availability assumptions:
Approver / owner:
Deployment date:
Verification:
Rollback trigger and procedure:
Review / expiry date:

This is the governance counterweight to “just lower the threshold.”

9. Cleanup and rollback

1. Confirm all evidence is outside the SonarQube project and scanner working directory.
2. Revoke the project-analysis token; record revocation time.
3. If the gate was created solely for this checkpoint, unassign and delete only that exact custom gate after evidence is preserved.
4. If the project was created solely for the lab, delete only academy-sq-ch11 after evidence is preserved.
5. Delete the local fixture/venv only if you no longer need to reproduce the packet.
6. Do not delete SonarQube volumes, database data, global scanner caches, or other projects as “cleanup.”

10. Verification checklist

• □ Both revision SHAs are present and distinct.
• □ Gate definition is identical across the pass/fail experiment.
• □ Project assignment is proven.
• □ Both scanner logs and report-task.txt files are preserved.
• □ Each gate result is correlated to the correct ceTaskId.
• □ Pass run shows coverage at/above threshold and gate OK.
• □ Fail run shows coverage below threshold and gate ERROR.
• □ Default scanner behavior is not mislabeled as gate enforcement.
• □ Wait-enabled behavior is captured.
• □ No credential value appears in the packet.
• □ Cleanup/revocation is recorded.
• □ Policy-change template contains owner, rationale, impact analysis, and rollback.

11. What Chapter 11 adds to a production operating model

After this checkpoint, a quality gate is no longer a colored badge. It is a versioned policy object connected to an explicit code population, an asynchronous analysis task, measurable conditions, a project assignment, and an enforcement mechanism.

The next chapter—New Code, Clean-as-You-Code, Baselines, and Legacy Modernization—takes the most important population in that model, “new code,” and makes its baseline and modernization consequences explicit.

Knowledge check

Official references and version notes

• Understanding quality gates — conditions, Sonar way, new/overall code, and the small-change fudge factor.
• Managing custom quality gates — creation, condition changes, permissions, and review/update workflow.
• Changing a project quality gate and fudge factor — project assignment and small-change configuration.
• Quality standards and new code — new-code definitions and Clean-as-You-Code context.
• Scanner-only analysis parameters — sonar.qualitygate.wait, timeout, and report-task.txt.
• CI integration overview — supported quality-gate enforcement patterns.
• Analysis overview — asynchronous server-side processing and quality-gate computation.
• Feature comparison — Community Build versus Server/Cloud branch and pull-request boundaries.
• Web API — authenticated API usage and Web API V2 migration guidance.
• SonarQube releases — current Community Build and Server/LTA release identities.
• SonarScanner CLI 8.1.0.6389 — scanner baseline used by the local lab.