We use a self-managed SonarQube Developer instance deployed in on-prem kubernetes cluster.
Our applications are scanned in containers using the sonarsource/sonar-scanner-cli image (last tag).
Following an issue encountered a few days ago with the JRE auto-provisioning feature, we disabled it (with the env variable SONAR_SCANNER_SKIP_JRE_PROVISIONING=true).
So, I was wondering if there was any reason to enable this feature in this case: the image already contains a JRE 17.
Auto-provisioning is mainly helpful on environments where you don’t control Java. But if you’re using the Docker image and keep it updated, keeping SONAR_SCANNER_SKIP_JRE_PROVISIONING=true is perfectly fine IMO.
That said, I can’t say I’m a fan of this change. SonarSource introduced JRE auto-provisioning to cover “what if scanners move to a newer LTS someday” and the “what it the scanner is executed a JDK 2x version that breaks our code” scenarios… and in the process gave the rest of us more moving parts, extra downloads, and new ways for things to break. To make it even funnier, the feature isn’t particularly useful right now anyway because the scanner itself is compiled for Java 17, so you already need a compatible JRE to run it. If it were compiled for Java 11, at least there’d be some extra flexibility. Instead, most of us just get the fun new task of disabling or troubleshooting something we never asked for. Progress, I guess.
