SonarScanner CLI Docker 11.0.0.1541_6.1.0 released

Hi all,

We’ve just released a new version of the SonarScanner CLI Docker image: 11.0.0.1541_6.1.0. We’d appreciate your feedback.

What changed?

  • Change the base image to support CFamily AutoConfig for SonarQube
  • Update the Scanner CLI to the latest version (6.1.0 native)

For now, we haven’t updated the LATEST tag. Since until very recently it was what we recommended using (We don’t anymore. Don’t do it. Change it if that’s what your current config is.) we’re going to wait just a little bit to update that tag. That will allow your early feedback to verify that everything works before we make automatic changes in the deployed pipelines of the folks who haven’t switched away from using LATEST yet.

Note that this is the only/last time we’ll delay updating LATEST. Next time, the update of LATEST will be simultaneous with the release.

 
Thanks,
Ann

5 Likes

Hi,

I will test on my Jenkins/Kubernetes infra soon (I’m still on 9.9 LTA)

For me I’m just a bit confused with the Java version used by the scanner.

According to Scanner environment | SonarQube Docs

The JRE auto-provisionning is done since version 6.0 of the scanner. The current image 11.0.0.1541_6.1.0 provide already the JRE as part of the scanner (/opt/sonar-scanner/jre) and use_embedded_jre=true

Does’t it means that we need to set sonar.scanner.skipJreProvisioning when running the scanner on the container image ? Shouldn’t it be something by default on the container image ? Or perhaps the JRE need to be removed from the image and always rely on JRE provisioning (which is the default)

Thanks for the clarification

Hi @jonesbusy

This is indeed a bit confusing. Let me try to explain.

One purpose of the scanner CLI is to bootstrap a SonarQube analysis without having to change the scanner every time you update your server.

So we want to decouple the requirements for running the Scanner CLI and running the Sonar analysis. Ideally, the Scanner CLI should have zero or very relaxed requirements. Since it is a Java program, we still need a JRE. We decided to provide packages where the JRE is already bundled, but maybe someday we will change to another strategy (maybe directly compile the scanner CLI to native binaries, for example).

The SonarQube analysis itself is also a Java program, but here, we want to be free to use a very recent Java runtime without affecting users. That’s why we added this JRE provisioning feature.

Does it clarify?

3 Likes

Thanks. This is more clear to me