Gradle plugin - set sonar property from another plugin

38 views
Skip to first unread message

mmind...@gmail.com

unread,
Apr 9, 2018, 3:12:09 PM4/9/18
to SonarQube
Hello,

I'm working on a project using gradle for builds, and Clover for code coverage (they do not want to switch to JaCoCo).  I have the Clover plugin enabled on the Sonar server.   When running the build, the gradle-clover-plugin produces an XML coverage report, which is then uploaded to the sonar server by the sonar-scanner-gradle plugin.  I noticed that the coverage numbers did not match, and eventually figured out this was due to Clover "excludes" patterns not being accounted for by the sonar-scanner-gradle plugin.  I was able to solve the problem with a workaround that involves writing to and reading from a project extension property:

clover {
    excludes = [
            '**/ExcludedClass.java',
            '**/excludedpackage/*.*',
    ]
    // set property that will be read by sonar plugin to match coverage exclusions
    project.ext.'sonar.coverage.exclusions' = excludes.join(',')
}

sonarqube {
    properties {
        // read coverage exclusions set by clover
        property "sonar.coverage.exclusions", project.ext.'sonar.coverage.exclusions'
    }
}

This is a bit of a hack...it would be preferable for the clover plugin to detect the sonar plugin within the project, and set the property directly.  I looked at the code, and I don't think there's a way to do this within the current plugin.  I'd like to have this support, and am happy to contribute a PR if someone has an idea for how to best accomplish this (I don't have much experience with gradle plugins).

Thanks!
 

Julien HENRY

unread,
Apr 10, 2018, 3:27:59 AM4/10/18
to SonarQube
Hi,

You can also think the other way around: the SonarQube plugin can detect the presence of the clover plugin, and extract configuration from it. This is something we already do for JaCoCo and Android. The only question is to know if the Clover plugin expose a stable API to get the data you need, because having to deal with breaking API changes depending on the plugin version is a nightmare.

++

Julien
Reply all
Reply to author
Forward
0 new messages