Merge JaCoCo coverage reports the "right" way

[3flex]

Advantages over the current config are that there's no cross project configuration using subprojects (which is discouraged), and that the generated HTML report now renders properly from the merged JaCoCo task outputs.

Although more advanced/technical than typical Gradle build scripts this technique is actually the recommended way to share outputs between projects.

[picklebento]

Advantages over the current config are that there's no cross project configuration using subprojects (which is discouraged), and that the generated HTML report now renders properly.

To paraphrase: If module B's test code covers module A's code, then module A's code would be counted as "covered" in jacoco. Is that correct?

Coverage report on my machine seems slightly improved with this config as well.

Would you mind sharing the jacoco output? (I assume our detekt-gradle-plugin code cannot be correctly calculated still)

[picklebento]

Using the implementation configuration feels weird: Would that create unnecessary tasks by the plugins applied in this build.gradle?

I am wondering if we could use a different configuration, or move the jacoco to a separate module.

[3flex]

Moving jacoco generation to a separate project/module makes sense to me. I believe a different configuration would work instead of implementation too. I can make those changes.

Would that create unnecessary tasks by the plugins applied in this build.gradle?

I don't believe so. But if there were unnecessary tasks, and they're not created during the configuration phase, there'll be no penalty to build performance. This is a jacocoTestReport build scan and a codeCoverageReport build scan for comparison. The only tasks created immediately or during configuration are from nexus-staging, binary-compatibility-validator, gradle.plugin-publish, github-release and sonarqube plugins.

The benefit of using configurations like this is it's more declarative so manually setting up task dependencies can be avoided, and only the tasks that need to be run are run. The disadvantage is the boilerplate.

[picklebento]

Can the following block of build script be removed

        subprojects
            .filterNot { it.name in examplesOrTestUtils }
            .forEach {
                this@jacocoTestReport.sourceSets(it.sourceSets.main.get())
                this@jacocoTestReport.dependsOn(it.tasks.test)
            }

I don't know jacoco enough to realize the actual benefit. The boilderplate might be fine since we do not add/change gradle modules often.

[codecov]

Codecov Report

Merging #3650 (f2ce3a7) into main (4d80329) will decrease coverage by 4.72%.
The diff coverage is n/a.

❗ Current head f2ce3a7 differs from pull request most recent head 0251e66. Consider uploading reports for the commit 0251e66 to get more accurate results

@@             Coverage Diff              @@
##               main    #3650      +/-   ##
============================================
- Coverage     83.48%   78.75%   -4.73%     
+ Complexity     2914     2900      -14     
============================================
  Files           452      473      +21     
  Lines          8766     9336     +570     
  Branches       1664     1722      +58     
============================================
+ Hits           7318     7353      +35     
- Misses          544     1075     +531     
- Partials        904      908       +4     

Impacted Files	Coverage Δ	Complexity Δ
...rturbosch/detekt/rules/style/StyleGuideProvider.kt	100.00% <0.00%> (ø)	3.00% <0.00%> (ø%)
...rbosch/detekt/rules/style/ObjectLiteralToLambda.kt
...kotlin/io/gitlab/arturbosch/detekt/DetektPlugin.kt	6.25% <0.00%> (ø)	0.00% <0.00%> (?%)
...o/gitlab/arturbosch/detekt/internal/SharedTasks.kt	0.00% <0.00%> (ø)	0.00% <0.00%> (?%)
...lab/arturbosch/detekt/internal/ClassLoaderCache.kt	85.71% <0.00%> (ø)	0.00% <0.00%> (?%)
.../io/gitlab/arturbosch/detekt/internal/DetektJvm.kt	0.00% <0.00%> (ø)	0.00% <0.00%> (?%)
...o/gitlab/arturbosch/detekt/invoke/DetektInvoker.kt	40.62% <0.00%> (ø)	0.00% <0.00%> (?%)
.../main/kotlin/io/gitlab/arturbosch/detekt/Detekt.kt	0.00% <0.00%> (ø)	0.00% <0.00%> (?%)
...itlab/arturbosch/detekt/extensions/DetektReport.kt	0.00% <0.00%> (ø)	0.00% <0.00%> (?%)
...gitlab/arturbosch/detekt/report/XmlReportMerger.kt	90.90% <0.00%> (ø)	5.00% <0.00%> (?%)
... and 14 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4d80329...0251e66. Read the comment docs.

[3flex]

To paraphrase: If module B's test code covers module A's code, then module A's code would be counted as "covered" in jacoco. Is that correct?

I believe that's already happening - this change is just about getting the data from each subproject's JaCoCo output, source files and compiled classes in the "right" way. So instead of the merge task reaching into directories manually, the relevant files are packaged by the new configurations (like coverageDataElements) in each project then that configuration is consumed by the new configurations in the root Gradle project. This helps decouple the builds.

Would you mind sharing the jacoco output?

I'm not sure if the line coverage differential in the JaCoCo HTML report run on my machine is actually consequential - now the report is picked up by Codecov you can see there's no difference in coverage reported when using the new task.