SonarScanner for Gradle

The SonarScanner for Gradle provides an easy way to start SonarCloud analysis of a Gradle project.

The ability to execute the SonarCloud analysis via a regular Gradle task makes it available anywhere Gradle is available (CI service, etc.), without the need to manually download, setup, and maintain a SonarScanner installation. The Gradle build already has much of the information needed for SonarCloud to successfully analyze a project. By configuring the analysis based on that information, the need for manual configuration is reduced significantly.

Prerequisites

• Gradle 7.3+
• Java 17

Bytecode created by javac compilation is required for Java analysis, including Android projects.

See also Scanner environment.

Configure the scanner

Installation is automatic, but certain global properties should still be configured. A good place to configure global properties is ~/.gradle/gradle.properties. Be aware that the scanner uses system properties so all properties should be prefixed by systemProp.

systemProp.sonar.host.url=https://sonarcloud.io

# Token generated from an account with 'Execute analysis' permission.
# It can also be set with the environment variable SONAR_TOKEN.
systemProp.sonar.token=<token>

Analyzing

The first step in the process is to activate the scanner in your build. Kotlin DSL is now the default choice for new Gradle builds. However, Groovy is still used by some developers. Apply the SonarQube plugin dependency to your build.gradle.kts file below:

plugins {
    id("org.sonarqube") version "versionNumber" // Replace with latest scanner version number
}

sonar {
  properties {
    property("sonar.projectKey", "myProjectKey")
    property("sonar.organization", "myOrganization") 
    property("sonar.host.url", "myHostUrl")
  }
}

plugins {
  id "org.sonarqube" version "versionNumber" // Replace with latest scanner version number
}

sonar {
  properties {
    property "sonar.projectKey", "myProjectKey"
    property "sonar.organization", "myOrganization"
    property "sonar.host.url", "myHostUrl"
  }
}

Ensure that you declare the plugins in the correct sequence required by Gradle, that is, after the buildscript block in your build.gradle file. More details on https://plugins.gradle.org/plugin/org.sonarqube.

Execute gradle build sonar and wait until the build has been completed, then open the web page indicated at the bottom of the console output. You should now be able to browse the analysis results.

Analyzing multi-project builds

To analyze a project hierarchy, apply the SonarQube plugin to the root project of the hierarchy. Typically (but not necessarily) this will be the root project of the Gradle build. Information pertaining to the analysis as a whole has to be configured in the sonar block of this project. Any properties set on the command line also apply to this project.

// build.gradle
sonar {
    properties {
        property "sonar.sourceEncoding", "UTF-8"
    }
}

Configuration settings shared between subprojects can be specified in a subprojects block.

// build.gradle
subprojects {
    sonar {
        properties {
            property "sonar.sources", "src"
        }
    }
}

Project-specific information is configured in the sonar block of the corresponding project.

// build.gradle
project(":project1") {
    sonar {
        properties {
            property "sonar.branch", "Foo"
        }
    }}

To skip analysis for a particular subproject, set sonar.skipProject to true.

// build.gradle
project(":project2") {
    sonar {
        isSkipProject = true
    }
}

Task dependencies

All tasks that produce output that should be included in the analysis need to be executed before the sonar task runs. Typically, these are compile tasks, test tasks, and code coverage tasks. To meet these needs, the plugin adds a task dependency from sonar on test if the Java plugin is applied. Further task dependencies can be added as needed. For example:

// build.gradle
project.tasks["sonar"].dependsOn "anotherTask"

Sample project

A simple working example is available at this URL so you can check everything is correctly configured in your environment: https://github.com/SonarSource/sonar-scanning-examples/tree/master/sonar-scanner-gradle

Adjusting the analysis scope

The analysis scope of a project determines the source and test files to be analyzed. 

An initial analysis scope is set by default. With the SonarScanner for Gradle, the initial analysis scope is:

• For source files: all the files stored under src/main/java (in the root or module directories).
• For test files: all the files stored under src/test/java (in the root or module directories). 

Since SonarScanner for Gradle also supports Groovy and Kotlin, the initial scope will also include src/main/kotlin or src/main/groovy for source and test files, depending on the type of project.

To adjust the analysis scope, you can:

• Adjust the initial scope: see below.
• And/or exclude specific files from the initial scope: see Analysis scope.

Adjusting the initial scope

The initial scope is set through the sonar.sources property (for source files) and the sonar.tests property (for test files). See Analysis parameters for more information.

To adjust the initial scope, you can do one of the following:

• Override these properties by setting them explicitly in your build like any other relevant gradle property: see Analysis scope.
• Use the scanAll option to extend the initial scope to non-JVM-related files. See below.

Using the scanAll option to include non-JVM-related files

You may want to analyze not only the JVM main files but also files related to configuration, infrastructure, etc. An easy way to do that is to enable the scanAll option (By default, this option is disabled.)

If the scanAll option is enabled, then the initial analysis scope of source files will be:

• The files stored in src/main/java (and src/main/kotlin or src/main/groovy, depending on the type of project).
• The non-JVM-related files stored in the root directory of your project.

Warning: The scanAll option is disabled if the sonar.sources property is overridden.

To enable the scanAll option:

• Set the sonar.gradle.scanAll property to True. 

Analysis property defaults

The SonarScanner for Gradle uses information contained in Gradle's object model to provide smart defaults for most of the standard analysis parameters, as listed below. Note that additional defaults are provided depending on the projects.

Gradle defaults for standard SonarCloud properties

Additional defaults for projects with the base or Java plugins applied

Additional default for Groovy projects

Additional defaults for Android projects

More default properties apply to Android projects (com.android.application, com.android.library, or com.android.test). By default, the first variant of type debug will be used to configure the analysis. You can override the name of the variant to be used using the parameter androidVariant:

// build.gradle
sonar {
    androidVariant 'fullDebug'
}

Passing manual properties / overriding defaults

The SonarScanner for Gradle adds a SonarQubeExtension extension to a project and its subprojects, which allows you to configure or override the analysis properties.

// build.gradle
sonar {
    properties {
        property "sonar.exclusions", "**/*Generated.java"
    }
}

SonarCloud properties can also be set from the command line, or by setting a system property named exactly like the SonarCloud property in question. This can be useful when dealing with sensitive information (e.g. credentials), environment information, or for ad-hoc configuration.

gradle sonar -Dsonar.verbose=true

While certainly useful at times, we recommend keeping the bulk of the configuration in a (versioned) build script, readily available to everyone. A SonarCloud property value set via a system property overrides any value set in a build script (for the same property). When analyzing a project hierarchy, values set via system properties apply to the root project of the analyzed hierarchy. Every system property starting with sonar will be taken into account.

Analyzing custom source sets

By default, the SonarScanner for Gradle passes on the project's main source set as production sources, and the project's test source set as test sources. This works regardless of the project's source directory layout. Additional source sets can be added as needed.

// build.gradle
sonar {
  properties {
    property("sonar.projectKey", "myProjectKey")
    property("sonar.organization", "myOrganization")
    property("sonar.host.url", "https://sonarcloud.io")
  }
}

More on configuring properties

Let's take a closer look at the sonar.properties {} block. As we have already seen in the examples, the property() method allows you to set new properties or override existing ones. Furthermore, all properties that have been configured up to this point, including all properties preconfigured by Gradle, are available via the properties accessor.

Entries in the properties map can be read and written with the usual Groovy syntax. To facilitate their manipulation, values still have their “idiomatic” type (File, List, etc.). After the sonar properties block has been evaluated, values are converted to Strings as follows: Collection values are (recursively) converted to comma-separated Strings, and all other values are converted by calling their toString() methods.

Because the sonar properties block is evaluated lazily, properties of Gradle's object model can be safely referenced from within the block, without having to fear that they have not yet been set.

Troubleshooting

If you get a java.lang.OutOfMemoryError

sonar {

  properties {

    property("sonar.scanner.javaOpts", "-Xmx512m")

  }

}

export SONAR_SCANNER_JAVA_OPTS=”-Xmx512m”

set SONAR_SCANNER_JAVA_OPTS=-Xmx512m

org.gradle.jvmargs=-Xmx512m

If you get a java.lang.OutOfMemoryError: Metaspace

sonar {
  properties {
    property("sonar.scanner.javaOpts", "--XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M")
  }
}

export SONAR_SCANNER_JAVA_OPTS=”-XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M”

set SONAR_SCANNER_JAVA_OPTS=-XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M

org.gradle.jvmargs=-XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M