Kotlin / kotlinx-kover

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Automatically update minBound if higher

tomasAlabes opened this issue · comments

Describe what you would like to clarify about Kover

Having a rule like this:

koverReport {
    defaults {
        verify {
            onCheck = true
            rule {
                minBound(79)
            }
        }
    }
}

I'd like to update the coverage number every time it goes up, without having to manually check it and update it.
Is there a way/pattern to do this?

Hi,
for your case, would you like to have an build.gradle file or another project file edited?

I think allowing the plugin to edit the build.gradle file is not consistent with Gradle principles.

You can write an additional script that will use the koverLog task to read the current coverage from the build log, compare it with the specified one and edit the file build.gradle.

You may read this value from anywhere: from a file, from the Gradle parameter, from properties.

But for consistency, it is recommended to place the results of the plugin in the build directory - from where it will be impossible to consistently read these values.

Accordingly, it is for your case that you need to write your own additional script that will change the environments after passing a successful Gradle build.

At the moment, the simplest way for obtaining coverage outside is the koverLog task and reading the values from build logs.

At the moment there are too few use cases to add any features to the plugin.

In any case, it is unlikely that the plugin itself will change the contents of the build.gradle file.

Perhaps we can add a task that will save the coverage to a file and in doLast{} you can read this value and update the build.gradle file or any other project file.

A task that writes the coverage to a file with an option to update it if the value is higher? Besides failing if the value is lower.

Again, the value doesn't have to be in the build.gradle for me, it's there because that's where the config is.

Not planned.
This feature doesn't mix well with the Gradle configuration cache.

The contents of the file can be read in this way, however, to do this, need to wait for the lazy configuration to be implemented.

If, after the corresponding releases, it is not possible to implement reading and writing value from the file, please create a new issue.