Unable To Launch Sonar Scanner CLI 10.0.0.1370_5.0.1 Container In Jenkins 2.462.3

SonarQube Server / Community Build
,
1

This is a Sonar Scanner issue, not related to Server or IDE, but Server is the closest category.

which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension): SonarQube 2025.3.1, Sonar Scanner CLI Docker Container 10.0.0.1370_5.0.1, Jenkins 2.462.3

We are upgrading the Sonar Scanner CLI container from 5.0.1 to 10.0.0.1370_5.0.1, with the goal of upgrading to latest (7.3), however, the container does not launch successfully in Jenkins. I know there are quite a number of changes in the container architecture it went to the container versioning change. When Jenkins tries to launch the new container we get the following message:

process apparently never started in /tmp/jenkins/workspace/SonarQube_Container_Testing_main@tmp/durable-bbfc43c6

Here is a sample Jenkins pipeline:

apiVersion: v1
kind: Pod
spec:
  containers:
    - name: sonarqube-5-0-1
      image: sonarsource/sonar-scanner-cli:5.0.1
      imagePullPolicy: IfNotPresent
      command:
        - sleep
      args:
        - 99d
      tty: true
    - name: sonarqube-10-0-0-1370-5-0-1
      image: sonarsource/sonar-scanner-cli:10.0.0.1370_5.0.1
      imagePullPolicy: IfNotPresent
      command:
        - sleep
      args:
        - 99d
      tty: true

Any thoughts on debugging or what is different about the 10.X version that Jenkins is having trouble with would be greatly appreciated.

Best regards,

Mark

2

Any particular reason you’re targeting this version, and not the latest (11.5.0.2154_7.3.0)?

This version came out a year and a half ago, and is certainly not maintained/supported.

If 10.x isn’t working, I’d suggest you jump right to 11.x and see if it behaves any differently.

3

Hi Colin,

We have already tried 11.X and were having the same issues, so I wanted to go back to the smallest amount of change possible, essentially ruling out any changes related to the Scanner CLI itself. It certainly seems to be related to the container architecture change.

4

Thanks @scmbuildguy, and sorry for the late reply.

A couple things:

This isn’t a Jenkins pipeline but a Kubernetes pod spec. While maybe relevant, could you please also share how your Jenkins pipeline is setup?

A few things have definitely changed I wonder if it could be related to this:

Do you know what user ID your CI is running under?

5

Hey Colin,

Ah, yes, that is the same issue, not sure how missed it in searching.

Example stage:
stage(‘sonarqube_10.0.0.1370_5.0.1’) {
steps {
container(‘sonarqube-10-0-0-1370-5-0-1’) {
script {
sh “sonar-scanner --version”
}
}
}
}

I was able to get additional logging for why the container was not coming up:

cp: can’t create ‘/tmp/jenkins/workspace/script.sh.copy’: Permission denied

this is a typical file that Jenkins writes (from inside the container) to the Jenkins workspace which has the commands that the script section is calling out. Due to running as scanner-cli not able to start

Best regards,

Mark

6

Update: I was able to get the container (also verified with 11.5.0.2154_7.3.0) to launch in my test pipeline if I specified to run with 1000:1000. So that is a win. Now I need to see if I can make the modifications to the dev pipeline to get a SonarQube scan to execute

Best regards,

Mark

8

More digging update:

We are running the container using the Kubernetes plugin in Jenkins. In order for the SonarQube container to be attached as an agent, there is another JNLP container in the K8s pod which opens up network access between the pod and the host VM. When a pipeline starts, it creates workspace directories with the user running in the JNLP container. So if the JNLP runs with default user, then when the SonarQube container runs it can not write files since it is running as a different user. If the JNLP container is set to run with 1000:1000, the SonarQube container launches successfully since it can write to the directory. The issue I am now running into is multiple containers (with different users) in the same pipeline. I have feeling I won’t be able to solve the issue without changing the permissions on the filesystem, thus affecting overall security level.

Best regards,

–Mark