chore: exclude the TypeScript probes from SonarQube Cloud analysis

[tbouffard]

Problem

The quality gate of #552 fails on C Reliability Rating on New Code, where A is required.

The eighteen bugs behind that rating are all in the TypeScript probes: thirteen in
tools/plugin-registry-probes/q4-generic-host-features/probe.ts, four in r2-instancetype-extraction/probe.ts, one in
q5-module-augmentation/combined/app.ts. Confirmed through the Sonar API for that pull request.

Those probes exist to measure what the TypeScript compiler accepts and rejects. Their errors, and the near-identical
files that explore variants of the same construct, are the measurement rather than a defect, and they are compiled by
their own tsconfig files rather than by any package. ESLint already ignores the directory for exactly this reason, see
the ignores entry in eslint.config.mjs.

Fix

Add .sonarcloud.properties at the repository root, excluding tools/** from analysis and from duplication
detection.

Why this file and not sonar-project.properties

This project uses automatic analysis, not a CI scanner. Evidence: no workflow mentions Sonar, no scanner config
exists in the repository, and the server reports sonar.autoscan.enabled=true for the project.

The Sonar documentation is explicit that the two files belong to different modes: "If you import a project that
already contains a sonar-project.properties file, SonarQube Cloud will ignore the parameters in your
sonar-project.properties file. To analyze your code with the settings defined in this file, you can turn off
automatic analysis and configure a CI/CD analysis."
(automatic analysis)

sonar.exclusions and sonar.cpd.exclusions are both in the documented list of properties supported by automatic
analysis. The file name is unchanged by the SonarCloud to SonarQube Cloud rename and is not listed in the deprecations
page.

Sequencing

Automatic analysis reads this file from the default branch, so it takes effect only once this is merged. #552 then
needs a new push to be re-analysed. Whether an exclusion retroactively clears issues already raised on New Code is not
documented, so the re-analysis is what will confirm the gate turns green.

Residual risk

The automatic analysis page states "Wildcard patterns are not allowed" immediately before its property list, while the
same sentence on the
initial scope page
is scoped only to sonar.sources and sonar.tests, and sonar.exclusions is documented everywhere else as taking
glob patterns. Public repositories on automatic analysis use globs there and are actively maintained, for instance
third-party/** in LizardByte/Sunshine and src-tauri/gen/** in betaflight/betaflight-configurator.

If the pattern turns out not to be honored, the fallback is the project's Administration > General Settings > Analysis
Scope > Files field, with the sonar.exclusions line removed from this file, since the file overrides the UI outright
rather than merging with it.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[tbouffard]

Closing this for now: the exclusion hardcodes tools/**, and that path is not settled.

The probes are expected to move, together with the analysis files that #552 proposes to gather into a subfolder. Merging an exclusion keyed on a path we are about to change would either silently stop matching, leaving the quality gate failing again for a reason nobody remembers, or force a second commit for the same decision.

The right order is: decide where the probes live, move them, then configure the exclusion against the final path.

What was established here is worth keeping, and none of it depends on the path:

• The project uses automatic analysis, not a CI scanner. No workflow mentions Sonar, no scanner config exists in the repository, and the server reports sonar.autoscan.enabled=true.
• Consequently sonar-project.properties would be ignored. The file to use is .sonarcloud.properties, at the root of the default branch. Both names are current; the SonarCloud to SonarQube Cloud rename did not rename the file.
• sonar.exclusions and sonar.cpd.exclusions are both in the documented list of properties supported by automatic analysis: https://docs.sonarsource.com/sonarqube-cloud/analyzing-source-code/automatic-analysis
• The configuration is read from the default branch, so it takes effect only once merged, and the pull request it is meant to unblock then needs a new push to be re-analysed.
• Residual risk to re-check at that point: the automatic analysis page says "Wildcard patterns are not allowed" right before its property list, while the same sentence elsewhere is scoped only to sonar.sources and sonar.tests. Public repositories on automatic analysis do use globs in sonar.exclusions. If it turns out not to be honored, the fallback is Administration > General Settings > Analysis Scope > Files, with no sonar.exclusions line in the file, since the file overrides the UI rather than merging with it.

Until then, #552 keeps failing its quality gate on "C Reliability Rating on New Code". The eighteen bugs are all in the probes: thirteen in q4-generic-host-features/probe.ts, four in r2-instancetype-extraction/probe.ts, one in q5-module-augmentation/combined/app.ts. That is expected, since their compiler errors are the measurement rather than a defect.

The branch chore/sonar_exclude_probes is kept so the file can be updated and reopened rather than rewritten.

[tbouffard]

Correction to the note above: the remote branch chore/sonar_exclude_probes was deleted when this pull request was closed, so it is not available for reuse as I wrote.

The content is not lost. The .sonarcloud.properties file, ten lines, is in the diff of this pull request, and the research that produced it is in the previous comment. Recreating it once the probes have a final path is a copy, not a rewrite.

The rest of the note stands: automatic analysis, .sonarcloud.properties at the root of the default branch, sonar.exclusions and sonar.cpd.exclusions both supported.