Open shanshin opened 8 months ago
I think this is related to https://github.com/Kotlin/kotlinx-kover/issues/443
In my workaround for that, I am currently configuring the koverHtmlReport in a somewhat hack way:
tasks.withType<KoverHtmlReport>().configureEach {
val reportDir = layout.buildDirectory.asFile.get().resolve("reports").resolve("kover")
val htmlReportDir =
reportDir.resolve(
when (name) {
"koverHtmlReport" -> "html"
"koverHtmlReportJvm" -> "htmlJvm"
"koverHtmlReportDebug" -> "htmlDebug"
"koverHtmlReportRelease" -> "htmlRelease"
else -> error("What is the kover html report name for $name?")
}
)
val cssDir = htmlReportDir.resolve("css")
val coverageCss = cssDir.resolve("coverage.css")
val ideaMinCss = cssDir.resolve("idea.min.css")
doLast {
// here I make rough edits to the CSS files to invert some of the colors
}
}
This workaround is sufficient for me to be able to look at the HTML reports without my eyes hurting.
The reason I wanted to bring this up here is to suggest that exposing the report directory for each kover report task could be a nice feature.
Then I could completely eliminate this part:
tasks.withType<KoverHtmlReport>().configureEach {
val reportDir = layout.buildDirectory.asFile.get().resolve("reports").resolve("kover")
val htmlReportDir =
reportDir.resolve(
when (name) {
"koverHtmlReport" -> "html"
"koverHtmlReportJvm" -> "htmlJvm"
"koverHtmlReportDebug" -> "htmlDebug"
"koverHtmlReportRelease" -> "htmlRelease"
else -> error("What is the kover html report name for $name?")
}
)
Of course, I could also possibly just simplify my workaround like:
val htmlReportDir = reportDir.resolve("html" + name.substringAfter("koverHtmlReport"))
But in any case, this still requires me as the user to implement some logic related to the variant names.
Also, of course https://github.com/Kotlin/kotlinx-kover/issues/587 would also help with this. But then, still, I need to know to look inside the "reports/kover" directory and I need to know the prefix is "html".
I hope this provides some more context into how users might want to modify reports. For my use case, perhaps the main takeaways are:
Worth noting that for my specific use case, I technically don't even need the report dir to be exposed as long as the CSS files are. But that's probably too specific of a consideration for my use case since I only needed to edit the CSS
@mgroth0, it seems that your use-case and https://github.com/Kotlin/kotlinx-kover/issues/443 is not quite related to the current task.
Your problem is that you need to read the directory for the each HTML report task, this is solved by simply exposing property
interface KoverHtmlReprt {
val reportDir: Provider<Directory>
}
Then you can write something like this
tasks.withType<KoverHtmlReport>().configureEach {
doLast {
val dir = reportDir.get().asFile
// do some changes in dir
}
}
You're right, it is different. And you are right that exposing reportDir
would be a good solution for my use case.
Still, I added my comment here because I thought maybe it would be useful to consider as this API is being designed. Looking at the big picture, I think you would be supporting users in two different ways to make their own reports:
reportDir
)Relates #590
What is your use-case and why do you need this feature? If the testing does not take place in one build run, but is distributed over several builds, for example, at different CI steps.
In this case, it is necessary to generate a binary report in each shard, and later generate a report from them: XML, HTML or verification.
Now user may use:
However, this is inconvenient for use in Gradle, because it does not into the concept of runnable Gradle tasks.
In this case, users need to write their own tasks, set up input and output properties in them, which takes some time and is not very obvious to a person who is not familiar with Gradle.
Describe the solution you'd like Create a set of users tasks to generate report from evaluated earlier binary reports.
*Manually specifying the root directories with source files is inconvenient, but in the first iteration we can leave it like this, because it is not very clear how to do it better: users need to include all source files, including all Android build variants, or how