Kotlin / kotlinx-kover

Apache License 2.0
1.25k stars 46 forks source link

Allow filtering/choosing which variants are aggregated in a root report #599

Open gmazzo opened 1 month ago

gmazzo commented 1 month ago

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:

dependencies {
    kover(":app")
    kover(":lib-android")
    kover(":lib-jvm")
}

Will produce correctly an aggregated report, taking main variant on JVM modules, and all variants (usually debug and release) on Android ones.

However, this is a problem (at least for us) in large-scale projects, with either complex variants (by using productFlavors for instance) or a large number of modules, as it will cause tall tests to run (testDebug and testRelease for instance), increasing the overall CI time exponentially.

We'd like to have granular control on which variants are aggregated. image 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:

// app's build.gradle.kts
kover.currentProject {
    providedVariant("release") {
        aggregate = false
    }
}
shanshin commented 1 week 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:

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

shanshin commented 1 week ago
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.