Automatically update minBound if higher

[tomasAlabes]

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?

[shanshin]

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

[tomasAlabes]

The build.gradle file

…

On Wed, Nov 29, 2023 at 14:35, Sergey Shanshin ***@***.***(mailto:On Wed, Nov 29, 2023 at 14:35, Sergey Shanshin <<a href=)> wrote: Hi, for your case, would you like to have an build.gradle file or another project file edited? — Reply to this email directly, [view it on GitHub](#515 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAFKYKHJ42KO62YUEMBXTCDYG422PAVCNFSM6AAAAAA77KBHDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZRHEYDSMZSGY). You are receiving this because you authored the thread.Message ID: ***@***.***>

[shanshin]

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.

[tomasAlabes]

I’d have to edit the build file because the min bound value is there. But I wouldn’t mind moving and updating the number somewhere else.

…

On Wed, Nov 29, 2023 at 16:42, Sergey Shanshin ***@***.***(mailto:On Wed, Nov 29, 2023 at 16:42, Sergey Shanshin <<a href=)> wrote: 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. — Reply to this email directly, [view it on GitHub](#515 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAFKYKA5BKUCSHJ7AFIYVCTYG5JYDAVCNFSM6AAAAAA77KBHDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZSGE3DENBXGU). You are receiving this because you authored the thread.Message ID: ***@***.***>

[shanshin]

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.

[tomasAlabes]

Maybe there could be a pattern or a task to do this with the plugin in the future? I think it's a very common use case to set the coverage bar and then increase it as it improves.

…

On Wednesday, November 29th, 2023 at 4:54 PM, Sergey Shanshin ***@***.***> wrote: 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. — Reply to this email directly, [view it on GitHub](#515 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAFKYKCQKLOLIEOYDSYDLXTYG5LD7AVCNFSM6AAAAAA77KBHDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZSGE4DIMJWGY). You are receiving this because you authored the thread.Message ID: ***@***.***>

[shanshin]

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.

[tomasAlabes]

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.

[shanshin]

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.