SonarQube for IDE Connected Mode and Developer Feedback Loops: Guided Hands-On Workflow

1. Local lab contract

2. Create a fixture whose rule behavior is easy to observe

mkdir -p sq-ch20-ide-lab/src
cd sq-ch20-ide-lab
git init -b main
git config user.email "learner@example.invalid"
git config user.name "SQ IDE Learner"

cat > src/decision.py <<'PYCODE'
def classify(a, b, c, d):
    score = 0
    if a:
        score += 1
    if b:
        score += 1
    if c:
        score += 1
    if d:
        score += 1
    if score >= 3:
        return "high"
    if score == 2:
        return "medium"
    return "low"
PYCODE

cat > sonar-project.properties <<'EOF'
sonar.projectKey=sq-ch20-ide-lab
sonar.projectName=SQ Chapter 20 IDE Lab
sonar.sources=src
sonar.sourceEncoding=UTF-8
EOF

cat > .gitignore <<'EOF'
.scannerwork/
evidence/
EOF

git add .
git commit -m "baseline IDE feedback fixture"
git rev-parse HEAD

The fixture is intentionally small. The lab uses the Python Cognitive Complexity rule python:S3776 only if that rule is active in the current analyzer/profile; verify it before changing anything. If the exact rule key or parameter changes in a future release, choose another current locally supported parameterized rule and record that substitution.

3. Create the disposable server project and baseline analysis

Create sq-ch20-ide-lab in the local Community Build UI. Create a narrowly scoped project-analysis token for scanner execution and export it as SONAR_TOKEN. This credential is not the one you will use in the IDE.

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/baseline
git rev-parse HEAD | tee evidence/baseline/revision.txt
sonar-scanner -X 2>&1 | tee evidence/baseline/scanner.log
cp .scannerwork/report-task.txt evidence/baseline/report-task.txt

CE_TASK_ID="$(sed -n 's/^ceTaskId=//p' .scannerwork/report-task.txt)"
printf '%s\n' "$CE_TASK_ID" | tee evidence/baseline/ceTaskId.txt
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/ce/task?id=$CE_TASK_ID" \
  | tee evidence/baseline/ce-task.json

Wait for a terminal Compute Engine state and record the baseline project profile, issue population, and Quality Gate. The purpose is to know what the server actually considers authoritative before the IDE is connected.

4. Verify/install the IDE extension

code --version
code --list-extensions --show-versions | grep -i "sonarsource.sonarlint-vscode" || true

# Optional install command when the VS Code CLI is available:
code --install-extension SonarSource.sonarlint-vscode

After installation, verify the version from the Extensions view or code --list-extensions --show-versions. Record the observed version in evidence/ide-version.txt. The course baseline is 5.9.1, but do not downgrade an already-supported later version solely to match the screenshot/menu wording.

5. Observe standalone state before binding

Open the repository folder in VS Code and let SonarQube for IDE analyze the Python file. Record:

• whether the workspace is currently unbound/standalone;
• the visible local issues for src/decision.py;
• the locally active status/parameter of python:S3776 if exposed;
• the extension Output/log pane;
• the Git branch and working-tree state.

Do not change the server yet. This is the “before” observation that makes synchronization causal rather than anecdotal.

6. Create the Connected Mode credential correctly

In the local SonarQube account’s Security page, generate a disposable user token for the lab developer. Give the user only the project visibility/permissions it actually needs. Do not copy the scanner’s project-analysis token into the IDE.

7. Connect and bind explicitly

In VS Code, open SONARQUBE SETUP → CONNECTED MODE and add a SonarQube Server connection:

1. Server URL: http://localhost:9000.
2. Authentication: the disposable user token.
3. Connection name: sq-ch20-local.
4. Bind the open workspace explicitly to project sq-ch20-ide-lab.

Then record the binding in an evidence note. If the extension proposes an automatic match from sonar-project.properties, inspect the proposed project key before accepting it. Automation convenience must not replace identity verification.

8. Create one disposable profile change

In Community Build, create a child/custom Python quality profile for the lab rather than editing Sonar way. Assign it only to sq-ch20-ide-lab. Find python:S3776 (Cognitive Complexity) and record its current threshold. Lower the threshold only enough that the fixture becomes a predictable local finding.

After saving the rule parameter, use the IDE’s binding update/synchronization action (or restart the IDE if appropriate) and record the extension log showing synchronization.

9. Compare before/after local behavior

Without changing src/decision.py, compare:

• standalone issue state;
• Connected Mode issue state after the custom profile is assigned;
• the exact rule key and synchronized threshold;
• the server project/profile assignment;
• the Git SHA, which should remain unchanged.

If the local issue changes while the source SHA is identical, the causal input was project policy synchronization. That is the effect this exercise is designed to prove.

10. Prove the server/CI handoff independently

Now run the scanner again on the same committed SHA using the separate project-analysis token. Preserve the new ceTaskId, Compute Engine state, issue result, and Quality Gate.

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

CE_TASK_ID="$(sed -n 's/^ceTaskId=//p' .scannerwork/report-task.txt)"
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/ce/task?id=$CE_TASK_ID" \
  | tee evidence/connected-server/ce-task.json

The IDE observation and server result may be related by profile synchronization, but they are still separate executions. The authoritative gate comes from the server analysis, not from the local squiggle disappearing or appearing.

11. Disconnect and clean up

1. Preserve the connection/binding/profile evidence first.
2. Remove the project binding and/or disposable connection from the IDE.
3. Revoke the IDE user token in SonarQube.
4. Revoke the project-analysis token.
5. Restore/delete the disposable custom profile/project only after evidence is exported.
6. Do not delete unrelated global profiles or credentials.

12. Challenge: choose the correct layer

The IDE still shows the old rule behavior after a server profile change. Before editing source, what should you inspect?

1. Confirm the workspace is bound to the intended project key.
2. Confirm the project is actually assigned the intended quality profile.
3. Update/refresh the binding and inspect the SonarQube for IDE log.
4. Confirm the changed rule is supported by local analysis.
5. Only then decide whether source changes are relevant.

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.