Open gmazzo opened 1 month ago
Sorry for delayed answer.
This is a shortcoming of the current documentation: it is not recommended to use the total reports for Android projects. It is for this purpose that custom options are designed.
The expected usage algorithm is as follows:
main
)kover {
currentProject {
createVariant("main") {
add("debug") // or add("jvm") in JVM-only subproject
}
}
}
dependencies {
kover(":app")
kover(":lib-android")
kover(":lib-jvm")
}
:koverHtmlReportMain
to generate HTML reportCustom 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.
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: