CLI-289 Coverage experiment: sonar ping command covered by integration tests

[kirill-knize-sonarsource]

No description provided.

[sonar-review-alpha]

Summary

This PR adds a new sonar ping command that checks connectivity to the configured SonarQube server. The command fetches and displays the server's status (UP/DOWN) and version information, with support for both human-readable text and JSON output formats. The feature is fully covered by integration tests, which validate authentication requirements, text output formatting, and JSON serialization.

What reviewers should know

Files to review:

1. Start with src/cli/commands/ping/index.ts — the command implementation is straightforward; it creates a SonarQubeClient, calls getSystemStatus(), and formats output based on the --json flag.
2. Check src/cli/command-tree.ts — only a small addition registering the ping command with authenticatedAction (requires valid auth).
3. Review integration tests in tests/integration/specs/ping/ping.test.ts — three scenarios: missing auth, text output, and JSON output.

Note on test coverage: This PR is labeled a "coverage experiment" and includes integration tests only. The command has no unit tests — validation happens through the full integration test harness with a fake SonarQube server.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[hashicorp-vault-sonar-prod]

CLI-289

[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]

Clean implementation overall, but there's one real bug: the ping command will fail or produce misleading output for SonarQube Cloud users.

🗣️ Give feedback

[sonar-review-alpha]

Bug: getSystemStatus() calls /api/system/status, which is a SonarQube Server endpoint. The login.ts command explicitly guards against calling it on cloud connections (else if (!isCloud)) for the same reason.

ResolvedAuth already carries auth.connectionType: 'cloud' | 'on-premise', so the fix is straightforward — either reject cloud connections with a clear error, or query a cloud-appropriate endpoint instead.

Suggested change

	const client = new SonarQubeClient(auth.serverUrl, auth.token);
	const status = await client.getSystemStatus();
	if (auth.connectionType === 'cloud') {
	throw new CommandFailedError(
	'sonar ping is not supported for SonarQube Cloud connections.',
	);
	}
	const client = new SonarQubeClient(auth.serverUrl, auth.token);
	const status = await client.getSystemStatus();

• Mark as noise