General requirements on scanner environment

This page describes requirements regarding the machine running the scanner, and the actions you may need to take in order to meet them.

The following is required to run the scanner that performs analysis:

• A 64-bit system.
• If the JRE auto-provisioning is not supported (see below), a Java runtime environment: 
  • Oracle JRE or OpenJDK.
  • Java 17 LTS.  
• To analyze JavaScript, TypeScript, or CSS, additional requirements exist: see JavaScript/TypeScript/CSS.

JRE auto-provisioning

With the JRE auto-provisioning, the SonarScanner detects the version of the JRE required on the machine running the SonarScanner and downloads it from the Sonar Server.  

The JRE auto-provisioning is currently supported by the SonarScanner CLI (from version 6.0), the SonarScanner for .NET (from version 7.0), and the SonarScanner for NPM (from version 4.0).

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 SonarQube GitHub Action can be configured for different target build technologies (.NET, Gradle, Maven, etc).

Maven / Gradle

If your whole Maven or Gradle build doesn't run on Java 17, we suggest first trying to base the whole build on one of those two 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:

# Maven build
mvn verify ...
export JAVA_HOME=/path/to/java-17
mvn sonar:sonar ...

# Gradle build
gradle build ...
export JAVA_HOME=/path/to/java-17
gradle sonarqube ...

Azure DevOps

All VM images available in Azure Pipelines for Microsoft-hosted agents already contain Java 17. You need to ensure your build pipeline uses the correct JDK version (JAVA_HOME_17_X64).

For self-hosted agents, you must ensure that you are using Java 17 by modifying your build pipeline to use JAVA_HOME and 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.

$env:JAVA_HOME=/path/to/java-17
$env:XAMARIN_JAVA_HOME=/path/to/java-8
msbuild.exe  /p:JavaSdkDirectory=$env:XAMARIN_JAVA_HOME

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 analysis.

Jenkins

You can define a new JDK in 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.

stage('SonarQube analysis') {
    tools {
        jdk "jdk17" // the name you have given the JDK installation in Global Tool Configuration
    }
    environment {
        scannerHome = tool 'SonarQube Scanner' // the name you have given the Sonar Scanner (in Global Tool Configuration)
    }
    steps {
        withSonarQubeEnv(installationName: 'SonarQube') {
            sh "${scannerHome}/bin/sonar-scanner -X"
        }
    }
}

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:

 stage('Build') {
 tools {
        jdk "jdk11" // the name you have given the JDK installation using the JDK manager (Global Tool Configuration)
    }
    steps {
        sh 'mvn compile'
    }
}
stage('SonarQube analysis') {
    tools {
        jdk "jdk17" // the name you have given the JDK installation using the JDK manager (Global Tool Configuration)
    }
    environment {
        scannerHome = tool 'SonarQube Scanner' // the name you have given the Sonar Scanner (Global Tool Configuration)
    }
    steps {
        withSonarQubeEnv(installationName: 'SonarQube') {
            sh 'mvn sonar:sonar'
        }
    }
}

This example is for Maven but it can be easily modified to use Gradle.

Classical pipelines

Set Job JDK version

You can easily set the JDK version to be used by a job 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. 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 have to manually set the JAVA_HOME variable to Java 17 when running the analysis.

To do this use the Tool Environment Plugin. This plugin lets 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:


export JAVA_HOME=$OPENJDK_17_HOME/Contents/Home
mvn $SONAR_MAVEN_GOAL