Forcing SonarScanner for linux to use local Java instead of the embedded one

Hi,

I’m currently using SonarQube Server 10.3 and running code scans from Jenkins using the Sonar Jenkins plugin. I install the SonarScanner v.6.2.1 as a tool in Jenkins, which then downloads directly the zip file with the scanner binaries into the agent. The version includes the Java runtime in it, so it uses it to run the scan.

The problem I’m having is that, one of the agents uses alpine as the base image, which is incompatible with the Java runtime included in the bundle. I’ve installed Java in the alpine image as a test but I cannot get the scanner to use that version instead of the embedded one. I’ve tried setting the SONAR_JAVA_PATH and JAVA_PATH as environment variables but it’s still not working. I always get an error like the following:

/home/jenkins/agent/tools/hudson.plugins.sonar.SonarRunnerInstallation/SonarScanner6/sonar-scanner-6.2.1.4610-linux-x64/bin/sonar-scanner: exec: line 66: /home/jenkins/agent/tools/hudson.plugins.sonar.SonarRunnerInstallation/SonarScanner6/sonar-scanner-6.2.1.4610-linux-x64/jre/bin/java: not found

Is there any way to force the scanner to use the local runtime?
Thanks.

Hey there.

Have you tried out what’s documented here for Jenkins?

Hi @Colin,

yes, I looked into that doc but it didn’t work. In the meantime, I think I found what was causing the issue. I haven’t tested it yet.
According to the discussion in this other thread, and from what I saw in the code, you need to use a specific bundle of the scanner or modify a specific file in order for the scanner to not use the embedded runtime. In the thread, there is a link to a documentation page but it doesn’t exist anymore.

Hey @Sepharat

I think there must be a misunderstanding somewhere, because when I configure my SonarQube Scanner Tool Installation like this:

And a pipeline like this (demonstrative purposes only, continue to refer to the docs):

pipeline {
  agent any
  stages {
    stage('SonarQube analysis') {
      steps {
        script {
            scannerHome = tool 'SQScanner621'// must match the name of an actual scanner installation directory on your Jenkins build agent
        }
          sh "${scannerHome}/bin/sonar-scanner"
      }
    }
  }
}

the logs show that a version without any embedded JRE is downloaded.

Unpacking https://repo1.maven.org/maven2/org/sonarsource/scanner/cli/sonar-scanner-cli/6.2.1.4610/sonar-scanner-cli-6.2.1.4610.zip to /var/jenkins_home/tools/hudson.plugins.sonar.SonarRunnerInstallation/SQScanner621 on Jenkins
...
09:50:48.993 INFO  SonarScanner CLI 6.2.1.4610
09:50:48.994 INFO  Java 17.0.13 Eclipse Adoptium (64-bit)
09:50:48.995 INFO  Linux 6.10.14-linuxkit aarch64

Indeed, this is my local Java version.

colinmueller@colins-macbook-air-2 /var % docker exec -it f8bfbb788216 sh
$ java -version
openjdk version "17.0.13" 2024-10-15
OpenJDK Runtime Environment Temurin-17.0.13+11 (build 17.0.13+11)
OpenJDK 64-Bit Server VM Temurin-17.0.13+11 (build 17.0.13+11, mixed mode)

The version embedded with flavors of the Scanner CLI that embed a JVM is 17.0.12.

What version of Java do you see getting used by the scanner? Are you doing anything differently than I am?

Yes, using the installer that downloads the bundle from Maven requires a local runtime as it doesn’t include it. But, in my case, I’m using the zip installer pointing to the linux bundle that comes with the runtime as I don’t want to depend on it. But that one doesn’t work when using alpine as it doesn’t include the correct libraries the runtime is compiled with. That’s why I was trying to find a way to use the local Java whenever the embedded runtime didn’t work without the need to use a different scanner bundle.
So, for those Jenkins agents that use alpine, based on what’s described in the post I linked, I’ll be forced to use the installer you used in your example and add something in my code (I’m using a shared library written in Groovy) to distinguish between the 2 cases.