MCP-57 Expand on integration tests against SQC

[nquinquenel]

---

Summary by Gitar

• New integration test suite:
  • Added sonarCloudIntegrationTest task for testing against real SonarQube Cloud staging.
  • Implemented a complete test harness (SonarCloudStagingHarness) allowing in-process MCP client execution against live staging environments.
• Infrastructure enhancements:
  • Created a shared project provisioning mechanism using a dedicated Java/Maven sample project (sample-java-hotspot).
  • Added comprehensive tool coverage tests for every MCP tool to ensure staging parity.
• CI updates:
  • Integrated sonarCloudIntegrationTest into a new weekly GitHub Actions workflow.
  • Added failure notification support for the new integration test suite.

_{This will update automatically on new commits.}

[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
java:S1118	its/projects/sample-java-hotspot/src/main/java/foo/Foo.java	22	Add a private constructor to hide the implicit public one.

_{Analyzed by SonarQube Agentic Analysis in 3.9 s}

[hashicorp-vault-sonar-prod]

MCP-57

[gitar-bot]

Code Review ✅ Approved 13 resolved / 13 findings

Expands integration test coverage against SonarQube Cloud staging, resolving numerous resource leakage and concurrency issues. Client-side filtering in ChangeIssueStatusSonarCloudIT remains problematic as it risks missing issues beyond the 10-item page limit.

✅ 13 resolved

✅ Bug: Temp storage dir leaks: non-recursive Files.delete on populated dir

📄 its/src/test/java/org/sonarsource/sonarqube/mcp/its/sonarcloud/harness/SonarCloudStagingHarness.java:119-125
close() removes the temp storage directory with Files.delete(tempStoragePath), which only deletes an empty directory. STORAGE_PATH is actively populated at runtime by the server (e.g. a logs/ subdirectory with rolling log files, per BackendService). As a result Files.delete throws DirectoryNotEmptyException, which is silently swallowed by the catch (IOException e) { // ignore } block, so every IT run leaks a sonarqube-mcp-sonarcloud-it-* temp directory tree. Use a recursive delete instead.

✅ Bug: newStagingClient overwrites tempStoragePath, leaking earlier dirs

📄 its/src/test/java/org/sonarsource/sonarqube/mcp/its/sonarcloud/harness/SonarCloudStagingHarness.java:58-63 📄 its/src/test/java/org/sonarsource/sonarqube/mcp/its/sonarcloud/harness/SonarCloudStagingHarness.java:119-126
tempStoragePath is a single field that is reassigned on every newStagingClient(...) call. If a test creates more than one staging client from the same harness, the directory from the earlier client is no longer referenced and is never cleaned up in close() (only the last one is). Track created storage directories in a list (mirroring clients/servers) and delete all of them on close.

✅ Bug: SonarCloudAnalyzedProject.getOrInitialize is not thread-safe

📄 its/src/test/java/org/sonarsource/sonarqube/mcp/its/sonarcloud/harness/SonarCloudAnalyzedProject.java:34-40 📄 its/src/test/java/org/sonarsource/sonarqube/mcp/its/sonarcloud/harness/SonarCloudAnalyzedProject.java:42-49
getOrInitialize() performs an unsynchronized check-then-act on the static fixture field and registers a shutdown hook, while cleanup() synchronizes on LOCK. The two methods use inconsistent locking. If JUnit ever runs test classes in parallel (it currently does not, but this is a latent hazard), two threads could each create a fixture — provisioning/analyzing duplicate staging projects and registering duplicate shutdown hooks. Guard both the read and write in getOrInitialize() with the same LOCK.

✅ Security: SonarCloud token passed as Maven CLI argument

📄 its/src/test/java/org/sonarsource/sonarqube/mcp/its/sonarcloud/harness/SonarCloudStagingFixture.java:130-142 📄 its/src/test/java/org/sonarsource/sonarqube/mcp/its/sonarcloud/harness/SonarCloudStagingFixture.java:169-183
analyzeMavenProject passes the staging token via -Dsonar.token=<token> as a process command-line argument. Command-line arguments are visible to other processes on the host (e.g. via ps) and may appear in CI logs/diagnostics. Since redirectErrorStream(true) captures all output and it is printed on failure, and --show-version/--errors are enabled, there is increased risk the token surfaces in logs. Prefer passing the token via an environment variable (SONAR_TOKEN) on the ProcessBuilder environment rather than a -D argument.

✅ Edge Case: bulk_delete query 'q' may match unrelated projects

📄 its/src/test/java/org/sonarsource/sonarqube/mcp/its/sonarcloud/harness/SonarCloudStagingFixture.java:146-151
cleanup() calls api/projects/bulk_delete with q="-" + randomSuffix. bulk_delete's q is a substring/fuzzy match over project keys/names in the org, not an exact key match. Because the suffix is a plain integer, this could match other concurrently-running ITs' projects in the shared sonarlint-it org whose suffix contains the same digits, deleting projects belonging to other runs. Consider deleting by the exact projects key parameter instead of a fuzzy q, e.g. pass projects=projectKey to bulk_delete.

...and 8 more resolved from earlier reviews

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

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

See analysis details on SonarQube Cloud