This message was deleted.
# community-support
s
This message was deleted.
l
• Observation 1 is the consequence of the Jacoco plugin configuring all
Test
tasks of the project for producing coverage data. • Observation 2 is the consequence of the Jacoco plugin only configuring a report task for the default
test
task. So your report configuration on the extension only applies to that report. • I do not know about observation 3 … @Tom Tresansky Could you take a look at the above?
šŸ‘€ 1
v
Also regarding Observation 1, keep in mind that the
.exec
file is the input for the
JacocoReport
task, it is an output of the
Test
task that is configured with the JaCoCo agent to produce that file. Regarding Observation 3, yes, the directory exists, but the message says it tries to read it as file which results in an access denied exception. You call the
executionData
method with a
TaskProvider
but the task is not capable of processing that properly. It only accepts
TaskCollection
,
Task
, and
Object
. So in your case the
Object
variant is used which is resolved as if you give it to
Project.files
and thus it's defined outputs are used, which is the test results directory, not the Jacoco data file. As the
TaskCollection
variant would anyway eagerly resolve all tasks and thus prevent task configuration avoidance, you can also directly use eager API and use the
Task
variant. So for example
executionData tasks.integrationTest
should work fine, as the JaCoCo plugin is simply not yet adapted to lazy APIs properly.
ā¤ļø 1
t
Thanks for the quick repliies! Yeah, I'd always thought build/jacoco/*.exec was generated by the jacoco plugin. @Vampire passing the
Task
rather than
TaskProvider
has fixed the issue.
m
Incredibly clear explanation!
šŸ™‡ā€ā™‚ļø 2
t
Thanks, @Vampire, for the great explanation! That linked issue is one we should consider as past of continuing work on the Provider APIs, which should become more of a focus for the team soon. @Tom Gregory What the reason is for aggregating execution data across multiple test suites with different `TestSuiteType`s? During development, we were wondering if there would be a need to add an easy way to configure a single report to aggregate either 1) all test suites of any type within a single project or 2) all test suites of any type across all project dependencies present in the
jacocoAggregation
configuration. The initial version of the aggregation feature did not offer this, but we are currently discussing how to expand and improve Test Suites and related features.
v
I usually prefer to have separate coverage for unit tests and integ tests, as I strive to have full coverage with unit tests and then with integ tests separately around 70 - 80 % in projects where I care about tests. But I also know the position that it is sufficient if any test type tests a code part. For that a combined report over all test types is helpful.
t
@Tom Tresansky I am sending coverage data to Sonaqube via
sonaqube
plugin. In the SonaQube UI there is a single code coverage statistic. Since I have a single-module Gradle project with unit + integration tests, this is why I wanted to combine the execution data into a single XML report to send to SonaQube. Let me know if there are any other approaches.
v
You can also give it multiple paths to multiple files
t
@Vampire do you mean setting
sonar.jacoco.reportPaths
?
v
yes