SonarScanner for Gradle
The SonarScanner for Gradle provides an easy way to start the scan of a Gradle project.
The ability to execute the SonarScanner analysis via a regular Gradle task makes it available anywhere Gradle is available (developer build, CI server, etc.), without the need to manually download, setup, and maintain a SonarScanner CLI installation. The Gradle build already has much of the information needed for the SonarScanner to successfully analyze a project. By preconfiguring the analysis based on that information, the need for manual configuration is reduced significantly.
- Gradle 5+
- Gradle 7+ and AGP 7+ for Android projects
- Java 11+
Bytecode created by
javac compilation is required for Java analysis, including Android projects.
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
First, you need 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:
If you still use Groovy DSL, it is supported for Gradle 2.1+. In that case, apply the SonarQube plugin dependency to your
build.gradle file below:
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 Gradle - Plugin: org.sonarqube.
Assuming a local SonarQube server with out-of-the-box settings is up and running, no further configuration is required.
You need to pass an authentication token using the
sonar.token property in your command line or configure it as part of your
gradle.properties file. Execute
gradle sonar -Dsonar.token=yourAuthenticationToken and wait until the build has 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.
A configuration shared between subprojects can be configured in a subprojects block.
Project-specific information is configured in the
sonar block of the corresponding project.
To skip SonarScanner analysis for a particular subproject, set
sonarqube.skipProject to true.
All tasks that produce output that should be included in the SonarScanner analysis need to be executed before the
sonar task runs. Typically, these are compile tasks, test tasks, and code coverage tasks.
Starting with v3.0 of the SonarScanner for Gradle, task dependencies are no longer added automatically. Instead, the SonarScanner plugin enforces the correct order of tasks with
mustRunAfter. You need to be either manually run the tasks that produce output before
sonarqube, or you can add a dependency to the build script:
A simple working example is available at this URL so you can check everything is correctly configured in your env:
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.
Gradle defaults for standard Sonar properties:
Notice that additional defaults are provided for projects that have the Java-base or Java plugin applied:
Groovy projects get all the Java defaults, plus:
Additional defaults when JaCoCo plugin is applied
Additional defaults for Android projects (
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
Passing manual properties / overriding defaults
The SonarScanner for Gradle adds a
sonar extension to the project and its subprojects, which allows you to configure/override the analysis properties.
Sonar properties can also be set from the command line, or by setting a system property named exactly like the Sonar property in question. This can be useful when dealing with sensitive information (e.g. credentials), environment information, or for ad-hoc configuration.
While certainly useful at times, we recommend keeping the bulk of the configuration in a (versioned) build script, readily available to everyone. A Sonar 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. Each 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.
More on configuring SonarQube 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
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.
If you get a java.lang.OutOfMemoryError: Metaspace
Increase the metaspace size in your
© 2008-2023, SonarSource S.A, Switzerland. Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution-NonCommercial 3.0 United States License. SONARQUBE is a trademark of SonarSource SA. All other trademarks and copyrights are the property of their respective owners.