Questions regarding Sonarqube Gradle plugin

SonarQube Server / Community Build
1

Hi guys,

Sonarqube Server (Community Edition): 8.2.0.32929 or SonarCloud

Gradle : 6.3

Kotlin: 1.3.70
Groovy: 2.5.10
Ant: Apache Ant™ version 1.10.7 compiled on September 1 2019
JVM: 11.0.4 (Oracle Corporation 11.0.4+10-LTS)
OS: Windows 10 10.0 amd64

build.gradle.kts

plugins {
    java
    jacoco
    id("org.sonarqube") version "2.8"
}

subprojects {
    apply(plugin = "java")
    apply(plugin = "jacoco")

    sourceSets {
        main {
            java {
                srcDir("main")
            }
        }
        test {
            java {
                srcDir("test")
            }
        }
    }

    repositories {
        mavenCentral()
    }

    dependencies {
        testImplementation("org.junit.jupiter", "junit-jupiter", "5.6.0")
    }

    tasks {
        test {
            useJUnitPlatform()
        }
    }
}

sonarqube {
    properties {
        property("sonar.projectKey", "samples")
        property("sonar.host.url", "http://localhost:9000")
        property("sonar.sourceEncoding", "UTF-8")
    }
}

I have a couple of questions regarding SonarQube task as a part of sonarqube-gradle-plugin. I’m trying to build a 3-stage (build/test/scan) CI pipeline for a multi-module Gradle/Java project. The Build stage - simply complies sources, Test - compiles tests, executes them and builds Jacoco coverage reports, and Scan runs SonarQube analysis. Because all necessary artifacts were prepared on the previous stages the SonarQube execution can look like: /gradlew sonarqube -x test

Questions:

  1. With the -x test exclusion Gradle shows these two deprecation notes for each subproject analyzed by SonarQube:
The configuration :projectA:testCompileClasspath was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project.	 
This behavior has been deprecated and is scheduled to be removed in Gradle 7.0.

The configuration :projectA:compileClasspath was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project.	 
This behavior has been deprecated and is scheduled to be removed in Gradle 7.0.

Could you advise the proper way to run only the SonarQube scan without performing extra steps? Technically, it looks like the -x test does exactly what I need, but the huge number of build deprecations (885 subprojects x 2 = 1770 warnings) in the console looks scary to me.

  1. I had the expectation that running SonarQube analysis on a number of independent subprojects (no relations between them) can be done in parallel. Fortunately, Gradle provides --parallel option for this which works perfectly on Build and Test stages speeding up the process in times.
    But, applying it to SonarQuby as ./gradlew --parallel sonarqube doesn’t give any benefits. Which I assume could make sense because there is only one root project SonarQube task running and it could be completed by a single thread. Is there something I can do to run the Sonar scanner in parallel to speed up the process?
    I looked at the Performance guide for large project analysis but didn’t find any specific advice there.

Thank you!

3

Hi,

  1. That’s probably a side effect of the sonarqube task forcing a dependency on test. See https://jira.sonarsource.com/projects/SONARGRADL/issues/SONARGRADL-59. This will probably get fixed with the next release.
  2. Unfortunately, no. SonarQube runs once for the root project where it’s applied and it’s single threaded. It won’t benefit from --parallel by itself.
4

Hi @dmeneses,

Thank you for the quick response. Considering the possibility to run SonarQube in parallel, would it make sense to run Sonar scanner against each subproject separately and somehow have the aggregated result in the end?

Thank you

5

That’s not possible. The scanner is not designed to scan each subproject separately and we would also have no way of aggregating the results.

6

Thank you! I got it.

Sorry, one more question. I also observe that the SonarQube task is not cacheable by Gradle.
Do you have any recommendations in mind about Sonar folder/files to be cached aside? Such as scanner Jars or .sonar/cache/ directory?

And the following question, if I don’t use some of those scanners (SCM, Ruby for instance) can I disable them somehow? By disabling, I mean to remove them from the execution chain even if they do nothing after that.

7

The analyzer jars are stored by default in {user.home}/.sonar/cache. It’s a good idea to cache these. To use something other than {user.home}, you can define the environment variable SONAR_USER_HOME .

There is no way to skip downloading any of the analyzer jars. If they are cached, the overhead of having them is practically 0.

8

Thanks a lot, @dmeneses!
Looking forward to seeing sonarqube plugin 3.0 in use. :slight_smile: