CLI-456 Add SCA eligibility SQ Server version check

[georgii-borovinskikh-sonarsource]

No description provided.

[sonarqubecloud]

Agentic Analysis: Early Results

Agentic Analysis and Context Augmentation are available on your project. Here are some issues that could have been prevented. Follow the links to learn how to put them into action.

1 issue(s) found across 1 file(s):

Rule	File	Line	Message
typescript:S109	tests/integration/specs/analyze/analyze-dependency-risks.test.ts	200	No magic number: 503.

_{Analyzed by SonarQube Agentic Analysis in 2.8 s}

[hashicorp-vault-sonar-prod]

CLI-456

[sonar-review-alpha]

Summary

Adds a SonarQube Server version check before SCA (Software Composition Analysis) operations. The analyze dependency-risks command now validates that the server is running SonarQube 26.4 or later before attempting to fetch SCA data. The check is performed early, only applies to on-premise servers (not Cloud), and provides clear error messages if the version is unsupported or the version endpoint is unreachable.

What reviewers should know

What changed:

• New assertServerSupportsSca() function in dependency-risks.ts that checks server version before SCA operations
• Imports fetchServerVersion and isAtLeast helpers from lib/server-info (not shown in diff; verify these exist)
• Constants: MIN_SCA_SERVER_VERSION = '26.4'

Key points for reviewers:

• Version check runs before the existing checkScaEnabled() call, ensuring early failure for incompatible servers
• Cloud connections skip the version check (appropriate since Cloud is always up-to-date)
• Three test scenarios cover: normal operation with 26.4, version too old (26.3), and unreachable version endpoint (503)
• Existing test at line 164 was updated to explicitly set .withVersion('26.4') to remain compatible

Watch for:

• Verify fetchServerVersion and isAtLeast functions exist in lib/server-info and work as expected
• Error messages are clear and include the actual server version when available

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonar-review-alpha]

Solid PR overall — the version check logic is clean and fits the existing patterns well. One genuine question needs answering before approval: the fake server returns a non-200 status code (503) with a valid JSON body for the "unreachable" test, but fetchServerVersion may or may not throw depending on how it handles non-2xx responses. The test needs to be verified to actually exercise the catch branch in assertServerSupportsSca.

🗣️ Give feedback

[sonar-review-alpha]

The test name says /api/system/status is "unreachable", but .withSystemStatusCode(503) causes the fake server to return a valid HTTP response with a 503 status — the TCP connection itself succeeds. Whether this exercises the catch branch in assertServerSupportsSca depends on whether fetchServerVersion throws on non-2xx responses.

From the gathered context, fetchServerVersion calls fetch() and returns response.json() — fetch() itself does not throw on non-2xx status codes; it only throws on network errors. If fetchServerVersion doesn't explicitly check response.ok and throw, a 503 response may be parsed silently (or throw a JSON parse error that is a different exception), meaning the test might be passing for the wrong reason, or the actual user-facing path for a real unreachable server isn't covered.

Please verify fetchServerVersion in src/lib/server-info.ts throws on non-2xx, and if so, whether a descriptive error scenario (e.g., a network-level failure or AbortError from the timeout) should also be covered.

• Mark as noise