Checkpoint Lab — Rules, Rule Types, Severities, Quality Profiles, and Customization

1. Scenario and pass condition

Evaluate whether a stricter Python cognitive-complexity threshold is appropriate for one synthetic project. The dossier must answer: what policy changed, which exact revision it affected, what result changed because of that policy, what projects were in scope, and whether rollback restored parent policy.

2. Assumptions manifest

3. Write predictions before the change

1. A: associating the child profile changes project-policy state only; source revision/scanner/indexed files remain unchanged.
2. B: overriding S3776 threshold to 3 changes child effective rule policy and should create an S3776 issue on the fixture.
3. C: each successful analysis has a distinct ceTaskId even with identical source revision.
4. D: Revert to Parent Definition removes the child override without modifying Sonar way.

For each prediction, write the independent evidence that would prove or falsify it.

4. Prepare a clean baseline

cd sonar-p09
test -z "$(git status --porcelain)" || { git status --short; exit 1; }
git rev-parse HEAD | tee checkpoint-revision.txt
sonar-scanner --version | tee checkpoint-scanner-version.txt

Record instance mode, Python Sonar way BUILT-IN/default markers, S3776 rule metadata and project/profile association before doing anything else.

5. Baseline analysis

read -rsp 'Project-analysis token: ' SONAR_TOKEN; echo
export SONAR_TOKEN SONAR_HOST_URL='http://127.0.0.1:9000'
sonar-scanner -X -Dsonar.host.url="$SONAR_HOST_URL" 2>&1 | tee checkpoint-baseline-debug.log
cp .scannerwork/report-task.txt checkpoint-baseline-report-task.txt

Record the terminal CE state, S3776 issue filter result and gate status separately.

6. Apply one controlled policy change

1. Extend Python Sonar way if the lab child does not already exist.
2. Associate only the lab project; do not change the Python default.
3. Record the inherited S3776 threshold and mode classification.
4. Set only the threshold to 3 (or a current valid value below measured fixture complexity).
5. Record actor, timestamp, reason and the override marker.

7. Same-revision overridden analysis

test "$(git rev-parse HEAD)" = "$(cat checkpoint-revision.txt)" || { echo 'Revision drift'; exit 1; }
sonar-scanner -X -Dsonar.host.url="$SONAR_HOST_URL" 2>&1 | tee checkpoint-overridden-debug.log
cp .scannerwork/report-task.txt checkpoint-overridden-report-task.txt

After CE success, record the S3776 issue message, actual complexity, allowed threshold, mode classification and gate state. Compare ceTaskId with the baseline to verify Prediction C.

8. Impact analysis

9. Roll back and prove parent restoration

1. Select Revert to Parent Definition for S3776.
2. Verify the override marker disappears and Sonar way was never modified.
3. Keep project association constant for the restore scan.

sonar-scanner -X -Dsonar.host.url="$SONAR_HOST_URL" 2>&1 | tee checkpoint-restored-debug.log
cp .scannerwork/report-task.txt checkpoint-restored-report-task.txt

After CE success, record restored rule-specific issue state. Historical issue/activity evidence may remain; that history is valuable and should not be erased.

10. Required evidence dossier

11. Verification checklist

• Exactly one synthetic project and one custom profile were affected.
• Source revision/indexed scope stayed constant.
• Instance mode and installed rule metadata were captured before mutation.
• Sonar way and the Python default were never modified.
• Baseline, overridden and restored scans have distinct task evidence.
• Issue evidence is filtered by exact rule key.
• Gate status is separate from scanner/CE success.
• Original failure/change evidence remains after rollback.
• No secret/token values or proprietary source are in the dossier.

12. Guarded cleanup

1. Revoke the project-analysis token and unset SONAR_TOKEN.
2. Remove the explicit child association only after rollback evidence is complete.
3. Delete the child profile only after proving no remaining project uses it and preserving its backup.
4. Delete the disposable project/fixture only after the dossier is complete.
5. Leave shared server, database/search, cache, default-profile and analyzer state untouched.

13. What Chapter 09 adds

You can now explain an issue as the intersection of known source scope and known rule policy: analyzer/repository, rule key/status, active profile, inheritance/override, project association, instance-mode taxonomy, same-revision analysis task and downstream gate. Chapter 10 can therefore focus on issue lifecycle—statuses, assignments, false positives and resolution—without confusing workflow decisions with profile policy.

Knowledge check

Official references and version notes

• Community Build — SonarQube rules — repositories, statuses, rule categories, custom/template rules and mode-dependent severity semantics.
• Community Build — Instance mode overview, including MQR Mode and Standard Experience.
• Community Build — Understanding quality profiles — built-in/default profiles, inheritance, overrides and project association.
• Community Build — Creating a quality profile — Extend, Copy, blank creation and import/export.
• Community Build — Editing a custom quality profile — activate/deactivate rules, customize parameters and Revert to Parent Definition.
• Community Build — Associating a quality profile with projects.
• Sonar Rules — Python S3776 — Cognitive Complexity rule used in the controlled parameter experiment.
• SonarQube releases — current Community Build and Server release identities.