sonarscan-dotnet: let SonarScanner provision its own JRE

[gunndabad]

Problem

The action hardcodes sonar.scanner.skipJreProvisioning=true and installs Java 17, so the SonarScanner engine is pinned to whatever JDK the action picks. SonarQube Cloud has since raised its minimum to Java 21, so the engine now fails to start during the end step.

The failure gives no indication that Java is involved — the scanner is writing its analysis payload to the engine over stdin, so a dead engine surfaces as a broken pipe and a SIGABRT:

Post-processing started.
Using Java found in JAVA_HOME: /opt/hostedtoolcache/Java_Zulu_jdk/17.0.20-8/x64/bin/java
Unhandled exception. System.IO.IOException: Pipe is broken.
   at SonarScanner.MSBuild.Shim.SonarEngineWrapper.Execute(...)
##[error]Process completed with exit code 134

This was pre-announced. Scans on Java 17 were already printing the warning below before they started failing outright:

Please upgrade to Java 21 or newer or use JRE auto-provisioning to keep this requirement always up to date.

Every consumer of this action is affected as soon as its scan next runs. It surfaced in get-information-about-pupils, where the scan job had been dormant for two months and failed on all three runs since it was re-enabled.

Change

• New skip-jre-provisioning input, defaulting to false — the scanner downloads the JRE the server asks for, so the Java version tracks SonarQube Cloud and future bumps don't break anyone.
• java-version default raised 17 → 21, so consumers that opt back into skipping still get a working engine today.
• README documents both, including the broken-pipe signature so the next person searching the error finds the cause.

Review note: this changes default behaviour

Consumers currently skipping provisioning implicitly will now download a JRE at scan time. That is the point — it is what makes the fix durable rather than moving the pin from 17 to 21 and waiting for the next bump. But it does mean runners that cannot reach the Sonar JRE download will need skip-jre-provisioning: true, and I don't know whether any DfE self-hosted or network-restricted runners fall into that category. If that's a real concern, the alternative is defaulting the input to true and having each repo opt in — say the word and I'll flip it.

Testing

I have not run this against a live pipeline — it needs a SONAR_TOKEN and a consumer repo. What I did verify: the YAML parses, and the generated begin command is well-formed in both modes, with the flag dropping out cleanly when disabled (same conditional-arg pattern already used for COVERAGE_ARG).

Worth a check on a real scan before merge.

Conflict with #242

#242 is open against the same file and edits the adjacent line, replacing the hardcoded sonar.coverage.exclusions with a conditional. Whichever merges second will need a trivial resolution — both changes are independent and use the same pattern.

🤖 Generated with Claude Code