I've a multi-module Groovy project using Gradle. I applied jacoco, sonarqube plugins.
I was able to
But Code Coverage
wasn't getting reported to SonarQube.
Here's my build.gradle
plugins {
id "org.sonarqube" version "2.0.1"
}
allprojects {
group = 'my'
version = '1.0-SNAPSHOT'
}
subprojects {
apply plugin: 'groovy'
apply plugin: "jacoco"
dependencies {
compile group: 'org.codehaus.groovy', name: 'groovy-all', version: '2.4.1'
testCompile group: 'org.spockframework', name: 'spock-core', version: '1.0-groovy-2.4'
testCompile group: 'org.assertj', name: 'assertj-core', version: '2.4.1'
}
}
I observed following log statements during a build.
No binary directories defined for project core.
Project coverage is set to 0% since there is no directories with classes.
I then tried adding following to subprojects or allprojects and still the coverage wasn't being reported to SonarQube.
sonarqube {
properties {
property "sonar.groovy.jacoco.reportPath", "${project.buildDir}/jacoco/test.exec"
property "sonar.jacoco.reportPath", "${project.buildDir}/jacoco/test.exec"
property "sonar.binaries", "${project.buildDir}/classes"
property "sonar.groovy.binaries", "${project.buildDir}/classes"
}
}
How can I enable reporting Jacoco Groovy code coverage to SonarQube?
You may have seen my comments as I battled with the same problem.
I've found the groovy plugin's site, where an issue is reported as follows:
sonar.groovy.binaries is resolved only once for the root project. In a multi-module project where the property is not defined on the root module but only on leaf modules this cause missing coverage information.
https://github.com/SonarQubeCommunity/sonar-groovy/issues/52
So even if it's set for your module:
":myspecialsubmodule.sonar.groovy.binaries" -> "/home/user/Projects/root-project/myspecialsubmodule/build/classes/main"
It won't work, until it's set for the root.
After setting the config specifically on the root (for now, until the issue is fixed) made it work for me.
property "sonar.groovy.binaries", "${project.buildDir.name}${File.separator}classes"
I will keep track of the github issue to know when I can remove this workaround.