Collect and aggregate jacoco results from multiple Gradle build steps

Avatar
Permanently deleted user
Created

Hey folks,

I have the following setup:

I have a monorepo with multiple, independent Gradle based builds inside. I added one build step for each project in the repo, using each subdirectory as working directory of that build. I use the jacoco enhancer from TC to generate reports of the junit4 test runs of each project.

What currently happens:

Only the report of the last build step is kept and made the one that is shown in the build overview. I can see in the logs, that all jacoco reports are generated as expected.

I'd like to achieve the following:

I want all reports to be aggregated and treated as the overall coverage of the build.

Any help is really appreciated!

Votes

0

Share

3 comments
Avatar
Permanently deleted user
Created

For everyone who visits this post and has the same issue, here is my solution:

  • Remove all jacoco options from any build step
  • Add the gradle jacoco plugin to each project you want to have coverage generated for
  • Add a command line build step at the very end of your build and fill it with something like the statement below
  • Please note, I use Kotlin in my project, please adjust your source path accordingly
echo "##teamcity[jacocoReport dataPath='%teamcity.build.workingDir%/project1/build/jacoco/test.exec %teamcity.build.workingDir%/project2/build/jacoco/test.exec %teamcity.build.workingDir%/project3/build/jacoco/test.exec' includes='trivago.* sps.*' excludes='*Test *Fixture *Proto *Outer' sources='%teamcity.build.workingDir%/project1/src/main/kotlin %teamcity.build.workingDir%/project2/src/main/kotlin %teamcity.build.workingDir%/3/src/main/kotlin']"
0
Avatar
Denis Lapuente
Created

Hi Mario,

thanks for the heads up! I hope your comment helps other people achieve the same.

To be honest, it feels kind of strange to have several different projects (i assume they are modules of a same final application), have them as build steps instead of separate build configurations, but then in the end want the coverage to be combined.

The typical approach to your scenario is to have the same VCS Root split across several different configurations, set up different checkout rules for each configuration, so only one project is built at a time, then combine the resulting artifacts. Keeping the testing and coverage separate usually helps finding issues by giving more granular information. You also can take advantage of having multiple build configurations in that all the different modules would build in parallel.

0
Avatar
Permanently deleted user
Created

I’m on mobile, so I owe you a longer version of my answer later. In my case, we use a monorepo for all projects of my team. We use Gradle composite builds to express dependencies between the projects. The artifacts from each build differ, sometimes it is a library, sometimes it is a full spring boot service that includes the result of a composite build from an Angular SPA. I can give you more insight into the real setup in a private chat.

0

Please sign in to leave a comment.