Checkpoint Lab — SonarQube for IDE Connected Mode and Developer Feedback Loops

1. Checkpoint scenario

A development team wants fast local feedback but does not want developers to treat editor state as a release gate. Your checkpoint is to bind VS Code to sq-ch20-ide-lab, synchronize one safe rule parameter, demonstrate a predictable local finding change at the same Git SHA, and then prove that the final governed result comes from a separate server analysis.

2. Exact assumptions and preflight

git branch --show-current
git rev-parse HEAD
git status --short
code --version
code --list-extensions --show-versions | grep -i sonar || true
sonar-scanner --version
curl -fsS "http://localhost:9000/api/system/status"

3. Predictions before changing state

Write at least these predictions in evidence/predictions.md:

• Prediction A: binding the workspace to sq-ch20-ide-lab will replace standalone rule ownership with server-profile-driven settings for locally supported rules.
• Prediction B: changing the disposable server profile’s python:S3776 threshold while keeping the Git SHA unchanged will change the local issue state after binding synchronization.
• Prediction C: the subsequent server analysis will produce a new ceTaskId and authoritative server result even though the IDE already displayed a local finding.
• Prediction D: revoking the IDE user token will break the Connected Mode trust path but will not invalidate the separate scanner project-analysis token until that token is revoked.

4. Capture the standalone baseline

1. Open the fixture in VS Code with SonarQube for IDE installed.
2. Confirm there is no active binding to sq-ch20-ide-lab.
3. Record extension version and local issue state for src/decision.py.
4. Record the locally visible configuration of python:S3776 if supported.
5. Save the extension Output/log excerpt without tokens.

Export a short note as evidence/ide-standalone.md. This is the control observation.

5. Create the correct connection and binding

Create a disposable SonarQube user token. In the Connected Mode panel, configure:

connection_name = sq-ch20-local
server_url = http://localhost:9000
credential_type = USER TOKEN
binding_project_key = sq-ch20-ide-lab
workspace = <exact local repository root>

Capture the binding success and project identity, but never the token value. If a shared binding configuration is exported, inspect it before committing and confirm it contains only supported project/server identity metadata, not user credentials.

6. Apply and verify one synchronized policy change

1. Create/assign a disposable custom Python quality profile to sq-ch20-ide-lab.
2. Record the parent/profile name and current python:S3776 threshold.
3. Change only that threshold so the fixed fixture crosses it.
4. Do not edit src/decision.py; prove the Git SHA is unchanged.
5. Refresh/update the Connected Mode binding.
6. Record the IDE log and local issue state after synchronization.

If the rule is unavailable locally in your installed version, select another locally supported parameterized Python rule and document the substitution. Do not manufacture success by editing source or disabling another rule.

7. Prove the independent governed server handoff

Use the scanner’s separate project-analysis token and analyze the committed revision:

export SONAR_HOST_URL="http://localhost:9000"
export SONAR_PROJECT_KEY="sq-ch20-ide-lab"
read -rsp "Project-analysis token: " SONAR_TOKEN; echo
export SONAR_TOKEN

mkdir -p evidence/server-handoff
git rev-parse HEAD | tee evidence/server-handoff/revision.txt
sonar-scanner -X 2>&1 | tee evidence/server-handoff/scanner.log
cp .scannerwork/report-task.txt evidence/server-handoff/report-task.txt

CE_TASK_ID="$(sed -n 's/^ceTaskId=//p' .scannerwork/report-task.txt)"
printf '%s\n' "$CE_TASK_ID" | tee evidence/server-handoff/ceTaskId.txt

curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/ce/task?id=$CE_TASK_ID" \
  | tee evidence/server-handoff/ce-task.json

After Compute Engine reaches a terminal successful state, capture the server issue result and Quality Gate. Your checkpoint is incomplete if it ends at “the IDE showed a squiggle.”

8. Diagnose one deliberate credential fault

Temporarily attempt to configure Connected Mode with the project-analysis token rather than the user token. Preserve the redacted failure/error. Then restore the user token.

This deliberate failure proves that authentication is purpose-specific: scanner success with a project-analysis token does not imply Connected Mode can authenticate with it.

9. Verification checklist

• ☐ Extension/IDE/server/scanner versions recorded.
• ☐ Exact Git branch/SHA and working-tree state recorded before and after synchronization.
• ☐ Standalone local issue/rule state preserved.
• ☐ Connection URL and bound project key independently verified.
• ☐ IDE credential identified as a user token; CI/scanner credential identified separately.
• ☐ Server quality profile and exact synchronized rule/parameter recorded.
• ☐ Same-SHA local issue change verified after synchronization.
• ☐ Fresh scanner run produced a new ceTaskId.
• ☐ Compute Engine terminal state and server Quality Gate recorded independently.
• ☐ Wrong-token-type failure preserved and repaired without weakening security.

10. Required evidence packet

11. Cleanup and rollback

1. Preserve/export the packet before mutation.
2. Remove the IDE project binding and disposable connection.
3. Revoke the IDE user token and verify it no longer authenticates.
4. Revoke the scanner project-analysis token and verify cleanup.
5. Restore/delete only the disposable custom profile/project created for this lab.
6. Do not alter unrelated global profiles, user accounts, CI secrets, databases, or server settings.

12. What this adds to the production operating model

Chapter 20 adds a fast, user-owned developer feedback loop to the governed platform without weakening the central analysis contract. Project identity and quality-profile policy can be synchronized into supported local analysis, while credentials remain separate by purpose and release decisions remain tied to server/CI evidence.

Chapter 21 moves from developer feedback into Users, Groups, Permissions, Tokens, Authentication, and Authorization, where the identity/permission model behind these user and analysis tokens becomes the primary subject.

Knowledge check

Official references and version notes

• SonarQube Server — Connected Mode — product role, supported IDE families, notifications, Open in IDE, and compatibility policy.
• SonarQube for VS Code — Connected Mode — binding, branch awareness, synchronization behavior, PR-analysis synchronization limitation, and connected-mode concepts.
• SonarQube for VS Code — Connected Mode setup — server URL, user-token authentication, project binding, and shareable binding configuration.
• SonarQube for VS Code — Rules and languages — server quality-profile synchronization, local/connected rule behavior, MQR/Standard Experience, and unsupported local rule classes.
• SonarQube for VS Code — Requirements — JRE 17+, embedded-runtime platforms, language-specific requirements.
• SonarQube — Managing tokens — user-token requirement for Connected Mode and analysis-token distinctions.
• SonarQube for VS Code 5.9.1 release — IDE extension baseline used in this chapter.
• SonarQube downloads — current Community Build and Server release streams.