-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow filtering/choosing which variants are aggregated in a root report #599
Comments
Sorry for delayed answer. This is a shortcoming of the current documentation: it is not recommended to use the total reports for Android projects. The expected usage algorithm is as follows:
kover {
currentProject {
createVariant("main") {
add("debug") // or add("jvm") in JVM-only subproject
}
}
}
dependencies {
kover(":app")
kover(":lib-android")
kover(":lib-jvm")
}
Custom variants allow to create different report slices by adding a variety of project sets and Android build variants to them - this way you can create different reports for different needs without changing of buildscripts |
kover.currentProject {
providedVariant("release") {
aggregate = false
}
} this approach is less flexible, it does not involve the simultaneous creation of alternative combinations of Android build variants for reports, however, as well as custom variant, it requires changes in each Android subproject. |
TL;DR: How to introduce custom variants to a total report?
Unfortunately total reports are currently (Kover 0.8.0) the only way for us (native Android app with Android- and Kotlin Library submodules) to collect code coverage for components whose tests are located in a different module. When not using total reports, code coverage stays zero for those components. Referencing modules explicitly like in your example works, but we need a global solution that works for all modules. So we decided to go with total reports which leads to the issue @gmazzo mentioned: Tests are executed for both debug and release, which doubles execution time. We want to skip tests for release and tried to do so by introducing a new Kover variant as follows:
Unfortunately this does not create a total report in the root's build directory when running Is there is a way to use custom variants with a total report? |
Sorry, I don't quite understand the question.
HTML report for
Could you clarify about this. If you do not specify If you allow the use of // root build.gradle.kts
kover {
merge {
// merge with all subprojects
subprojects()
// create reports variant 'main'
createVariant("main") {
// used plugins
val isAndroid = project.plugins.hasPlugin("com.android.application") || project.plugins.hasPlugin("com.android.library")
if (isAndroid) {
add("debug")
} else {
add("jvm")
}
}
}
} then, if you call the |
Thank you for your response, it is much appreciated!
In my example, when configuring a variant "main" for every subproject and then executing
By "those components" I mean classes that are being tested in another module. Without using Kover's total reports, I was not able to generate code coverage for those classes.
This leads to the following error on Gradle Sync:
This is the same error I receive when trying to create a Kover variant for the root project which, in our case, is not a JVM library module. |
We managed to fix the redundant execution of
This skips all tests for the release build variant and in our case cuts execution time in half. @gmazzo Maybe this will solve your problem as well? |
Let's clarify a little bit
please, add kover dependencies to the config of root project // root build.gradle.kts
dependencies {
kover(project(":some:subproject"))
// ... all necessary subprojects
}
You can add an analysis to understand whether there is a JVM in the subproject or not, or use the optional parameter like this: // root build.gradle.kts
kover {
merge {
// merge with all subprojects
subprojects()
// create reports variant 'main'
createVariant("main") {
// used plugins
val isAndroid = project.plugins.hasPlugin("com.android.application") || project.plugins.hasPlugin("com.android.library")
if (isAndroid) {
add("debug")
} else {
// add classes and tests from JVM target if it exists
add("jvm", optional = true)
}
}
}
} |
@shanshin I agree that I might have confused myself in the process and mixed up total- with merged reports. Thanks for clearing it up! Our current solution - using total reports, if I got you right - looks (dumbed down) like this:
This way tests only run for the debug build variant (1) and |
As for my current understanding, the whole concept of dealing with tasks is an antipattern on Gradle.
I was expecting more a convention over configuration approach. So, we park the migration for now. I was looking into it for a possible replacement of JaCoCo but we decided to wait a bit while it's gets more mature. |
@Faltenreich, using |
I agree that dealing with Gradle tasks is a sub-par solution, but the best we have so far and in our case fitting to our requirements (we do not have relevant code at the specific source set for release). |
@Faltenreich
in one place only in the root project requires much fewer configuration changes, and is also more reliable by excluding all unspecified sources and tests |
@shanshin I can confirm that your code snippet works exactly as intended and that were able to replace our workaround with your solution. Thank you for your recommendation and this awesome tool! All the best <3 |
What is your use-case and why do you need this feature?
Since
0.8.0-Beta2
, Kover successfully aggregates Android modules.Given the following setup at the root project:
Will produce correctly an aggregated report, taking
main
variant on JVM modules, and all variants (usuallydebug
andrelease
) on Android ones.However, this is a problem (at least for us) in large-scale projects, with either complex variants (by using
productFlavor
s for instance) or a large number of modules, as it will cause tall tests to run (testDebug
andtestRelease
for instance), increasing the overall CI time exponentially.We'd like to have granular control on which variants are aggregated.

https://scans.gradle.com/s/2nb3nedv4ntsm/timeline?details=txc6dqjkewdsm&expanded=WyIwLjEiXQ&show=predecessors
Describe the solution you'd like
Having some kind of DSL to choose which variants are aggregated.
With the current DSL approach (which I'll probably suggest improvements in another ticket) it would be something like this:
The text was updated successfully, but these errors were encountered: