Scanner environment
On this page
The table below describes what is required to run the scanner that performs analysis.
Category | Description |
---|---|
Supported operating system |
Note that z/OS is not supported. |
Java runtime environment | Depending on your SonarScanner, JRE may be auto-provisioned. JRE auto-provisioning is currently supported by:
If your SonarScanner doesn't support JRE auto-provisioning, the following Java runtime environment is required:
See If JRE auto-provisioning is not supported below for the actions you may need to take to meet these requirements. |
Additional requirements may exist for specific scanners or languages. Check the respective SonarScanner page in Advanced setup > CI-based analysis and language pages in Advanced setup for possible additional requirements. In particular, to analyze JavaScript, TypeScript, or CSS, additional requirements exist: see JavaScript/TypeScript/CSS.
- The requirement on the Java runtime environment refers only to the version of Java used by the scanner itself to run. It does not restrict the versions of Java that can be analyzed by the scanner. In addition, the required version changes with successive versions of the scanner.
- In rare cases, you may want to disable the auto-provisioning. To do so, set
sonar.scanner.skipJreProvisioning
totrue
.
If JRE auto-provisioning is not supported
This section describes the actions you may need to take depending on your environment in order to make sure the required Java version is used for the analysis.
GitHub Actions
The GitHub Action for SonarQube Cloud can be configured for different target build technologies. You can find samples for .NET, Gradle, Maven and a generic one, all running with JDK11 here.
If you follow these examples, we recommend using the minimum recommended version mentioned at the top of this page.
Maven / Gradle
If your whole Maven or Gradle build doesn't run on Java 17, we suggest first to try to base the whole build on one of those versions of Java. If it's not compatible, then you can override the JAVA_HOME
environment variable just before the analysis step, as shown here:
Azure DevOps
All VM images available in Azure Pipelines for Microsoft-hosted agents already contain Java 17. There is no further action required. For self-hosted agents, you must ensure that you are using Java 17. You can either modify your build pipeline to ensure that it runs with Java 17 by default, or override the JAVA_HOME
environment variable just before running the analysis.
Xamarin
For the specific case of Xamarin, which only allows Java 8, you will need to specify a Java 8 path separately when invoking MSBuild (using, for example, XAMARIN_JAVA_HOME
), and then leave the JAVA_HOME
environment variable for the scanner only.
Dockerfile
Multiple base images can be used to run your build with Java 17, here are some examples:
openjdk:17-jdk-slim
gradle:8.2.0-jdk17-jammy
If your build is not compatible with Java 17, then you can override the JAVA_HOME
environment variable to point to Java 17 immediately before running the scanners.
Jenkins
You can easily define a new JDK version by navigating to Manage Jenkins > Global Tool Configuration if you have the JDK Tool Plugin installed.
Declarative pipelines
If you are using a declarative pipeline with different stages, you can add a 'tools' section to the stage in which the code scan occurs. This will make the scanner use the JDK version that is specified.
If you are analyzing a Java 11 project, you probably want to continue using Java 11 to build your project. The following example allows you to continue building in Java 11, but will use Java 17 to scan the code:
This example is for Maven but it can be easily modified to use Gradle.
Classical pipelines
Set Job JDK version
- Set the JDK version to be used by jobs in the General section of your configuration. This option is only visible if you have configured multiple JDK versions under Manage Jenkins > Global Tool Configuration.
Set 'Execute SonarQube Scanner' JDK version
- If you are using the "Execute SonarQube Scanner" step in your configuration, you can set the JDK for this step in the configuration dialog. By using this approach, you can use JDK 17 only for the code scanning performed by SonarQube Cloud. All the other steps in the job will use the globally configured JDK.
Java 11 projects
- Jenkins does not offer functionality to switch JDKs when using a Freestyle project or Maven project configuration. To build your project using Java 11, you will have to manually set the
JAVA_HOME
variable to Java 17 when running the analysis. - This can be done by using the Tool Environment Plugin. This plugin lets you expose the location of the JDK you added under Manage Jenkins > Global Tool Configuration.
- The location of the JDK can then be used to set the
JAVA_HOME
variable in a post step command, like this:
Was this page helpful?