With the new release of Release 11.2.0.1836_7.0.1 · SonarSource/sonar-scanner-cli-docker · GitHub our pipelines started failing:
18:31:25.124 ERROR Failed to query server version: . Please check the property sonar.token or the environment variable SONAR_TOKEN.
Unless that cli stopped supporting LTA 9x ? But I can not find anything in the changelog
For version 9.9 (LTS community), try 11.1.1.1661_6.2.1
ref: SonarScanner
Yes that is how we were able to fix it, but we did not see anything in the changelog? Given its LTA assumption was made there was longterm support 
Maybe good to have a matrix table somewhere with the different supported versions across tools/servers?
edit: this is happening with SonarQube Server Community Edition - v9.9.5 (build 90363).
In a number of Python and TypeScript projects, using GitLab CI, I’m using sonarsource/sonar-scanner-cli:latest as the image for an analyze job.
The jobs are based on this minimal config:
analyze:
image:
name: sonarsource/sonar-scanner-cli:latest
entrypoint: [""]
stage: analyze
variables:
SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar" # Defines the location of the analysis task cache
GIT_DEPTH: "0" # Tells git to fetch all the branches of the project, required by the analysis task
cache:
key: "${CI_JOB_NAME}"
paths:
- .sonar/cache
script:
- sonar-scanner
allow_failure: true
only:
- main
Since yesterday, those jobs fail with:
INFO Scanner configuration file: /opt/sonar-scanner/conf/sonar-scanner.properties
INFO Project root configuration file: /builds/{{group}}/{{project}}/sonar-project.properties
INFO SonarScanner CLI 7.0.1.4817
INFO Java 17.0.14 Amazon.com Inc. (64-bit)
INFO Linux 4.19.0-18-amd64 amd64
INFO User cache: /builds/{{group}}/{{project}}/.sonar/cache
ERROR Failed to query server version: . Please check the property sonar.token or the environment variable SONAR_TOKEN.
INFO EXECUTION FAILURE
Note that the SONAR_TOKEN is still in place and worked 2 days ago in those projects, has not expired, and is right now successfully in use in some gradle projects’ CIs (where plugins contain id "org.sonarqube" version "6.0.1.5171")
I’ve switched from sonarsource/sonar-scanner-cli:latest (=> 11.2) to sonarsource/sonar-scanner-cli:11.1, and the analyses are working again.
Hey there.
What version of SonarQube are you using in your environment?
Hi! I’m using sonarsource/sonar-scanner-cli:latest in the CI script. According to the CI log, it points to SonarScanner CLI 7.0.1.4817
Oh, for sonarQube Server. I’m on Community Edition - v9.9.5 (build 90363) right now
Hi folks,
Can anyone having the issue run the scanner with verbose logs and share the output? Passing -X argument should do it.
Thanks!
@adrai I’ve moved your post into a very similar thread.
Coming right up, I’ll just need a minute to redact some stuff of course
Here we go
$ sonar-scanner -X -Dsonar.projectVersion=$SONAR_PROJECT_VERSION_NAME -Dsonar.qualitygate.wait=true
INFO Scanner configuration file: /opt/sonar-scanner/conf/sonar-scanner.properties
INFO Project root configuration file: /builds/{{group}}/{{project}}/sonar-project.properties
INFO SonarScanner CLI 7.0.1.4817
INFO Java 17.0.14 Amazon.com Inc. (64-bit)
INFO Linux 4.19.0-18-amd64 amd64
DEBUG Scanner max available memory: 15 GB
DEBUG uname -m returned 'x86_64'
DEBUG Mapping default scanner JVM truststore location '/usr/lib/jvm/java-17-amazon-corretto.x86_64/lib/security/cacerts' to new properties
DEBUG Create: /builds/{{group}}/{{project}}/.sonar/cache
INFO User cache: /builds/{{group}}/{{project}}/.sonar/cache
DEBUG Create: /builds/{{group}}/{{project}}/.sonar/cache/_tmp
DEBUG Using truststore: /usr/lib/jvm/java-17-amazon-corretto.x86_64/lib/security/cacerts
DEBUG Loading OS trusted SSL certificates...
DEBUG This operation might be slow or even get stuck. You can skip it by passing the scanner property 'sonar.scanner.skipSystemTruststore=true'
DEBUG Loaded [1029] system trusted certificates
DEBUG Loaded truststore from '/usr/lib/jvm/java-17-amazon-corretto.x86_64/lib/security/cacerts' containing 147 certificates
DEBUG --> GET {{sonar_host}}/api/v2/analysis/version
DEBUG <-- 401 {{sonar_host}}/api/v2/analysis/version (217ms, 0-byte body)
ERROR Failed to query server version: . Please check the property sonar.token or the environment variable SONAR_TOKEN.
org.sonarsource.scanner.lib.internal.MessageException: Failed to query server version:
at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.getServerVersion(ScannerEngineBootstrapper.java:271)
at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.bootstrap(ScannerEngineBootstrapper.java:144)
at org.sonarsource.scanner.cli.Main.analyze(Main.java:76)
at org.sonarsource.scanner.cli.Main.main(Main.java:64)
Caused by: org.sonarsource.scanner.lib.internal.http.HttpException:
at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.callUrl(ScannerHttpClient.java:139)
at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.callApi(ScannerHttpClient.java:123)
at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.callRestApi(ScannerHttpClient.java:104)
at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.getServerVersion(ScannerEngineBootstrapper.java:259)
... 3 common frames omitted
DEBUG Scanner engine bootstrapping failed
INFO EXECUTION FAILURE
INFO Total time: 0.947s
Thanks @adrai this is useful.
For SonarQube 9.9, the call to /api/v2/analysis/version is expected to fail but with a 404 error (this endpoint was only introduced in SonarQube 10.6), but we can see here it is failing with 401.
Do you have some kind of proxy between your CI and your SonarQube Server? Any special SSL configuration, maybe even client certificate authentication?
We have a whole architecture for our tooling and everything. Load balancers and reverse proxies may be involved, yes.
Do you suppose that upgrading our Sonar server to latest LTA would also fix the issue, then?
So far, I don’t think the Server version is involved. I already detected a regression in the Scanner CLI 7.0+ on the way SSL truststore is configured, so maybe this is affecting you.
By chance, have you configured the Scanner SSL by putting certificates in the ~/.sonar/ssl/truststore.p12 or ~/.sonar/ssl/keystore.p12?
Ah all right. Not to my knowledge, no we haven’t.
I’m gonna try with the latest community build this time.
EDIT: it worked with server v25.2.0.102705 and cli 11.2
Hi,
After more investigation, here are new details:
SONAR_TOKEN env variablesonar.token scanner properties have only been introduced in SonarQube Server 10.0, so setting it is normally useless for people running on SonarQube Server 9.9sonar.token over sonar.login.I will release a bugfix, but I would appreciate if people running on SonarQube Server 9.9 could confirm they are both setting sonar.token and sonar.login to the token value. If not, I am puzzled how the analysis could have succeeded before, since again, SONAR_TOKEN/sonar.token is ignored by 9.9.
If my investigation is correct, for people on 9.9, simply removing any SONAR_TOKEN or sonar.token should fix the issue.
I would be happy to hear if I am right.
BTW here is the ticket for the details.
Thanks
My bad, I found that SonarQube Server 9.9 is supporting passing a token using SONAR_TOKEN env variable (but not sonar.token). So forget my assumption about passing both sonar.token and sonar.login.
Now I think I understand the full problem, and updates will be posted in the JIRA ticket.
Thanks all for the feedback!