Sonar scanner cli using SonarCloud reports "Analyzing on SonarQube server 8"

  • ALM used: Bitbucket
  • CI system used: Jenkins / Docker / Podman
  • Scanner command used when applicable: see below
  • Languages of the repository: Java + multiple others
  • SonarCloud project is public: no
  • Error observed: no error
  • Potential workaround: n/a

We run our Sonar Analysis in a containerized CLI (using SonarCloud), when looking at the logs, I see:
and outdated version ( of SonarCube (not SonarCloud) mentioned. The results actually end up in SonarCloud.

podman -r run -t --rm \
-v /MYCODE:/usr/src \
-w /usr/src/ \
-e SONAR_TOKEN=**** \

Partial logs

INFO: Scanner configuration file: /opt/sonar-scanner/conf/
INFO: Project root configuration file: /usr/src/
INFO: SonarScanner
INFO: Java 17.0.8 Alpine (64-bit)
INFO: Linux 4.18.0-477.27.1.el8_8.x86_64 amd64
INFO: SONAR_SCANNER_OPTS= -Dsonar.newCode.referenceBranch=master -Dsonar.organization=OURORG -Dsonar.projectKey=OURPOROJECT**/*.jar -Dsonar.coverage.jacoco.xmlReportPaths=**/jacoco.xml -Dsonar.qualitygate.wait=true
INFO: User cache: /opt/sonar-scanner/.sonar/cache
INFO: Analyzing on SonarQube server

I would expect SonarCloud to internally run on something newer,

1 Like


You’ve noticed a vestigial artifact. When SonarCloud was born, it shared a code base with SonarQube. Eventually (during the SonarQube 8.0 cycle) the code bases split. Some of the analyzers say SonarQube 8.0, as you’ve noted, and some say SonarCloud, with a more up-to-date version.

We’ve actually had some internal discussion on this topic, recently, and there are tickets in to do something about it. But in the meantime, it’s harmless and can be safely ignored.


1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.