From 17613460840975cbbf1c17cdd8018a9a9895532d Mon Sep 17 00:00:00 2001
From: OmarAlJarrah
Date: Sat, 18 Jul 2026 04:08:08 +0300
Subject: [PATCH 1/2] docs: correct the Kover coverage floor claims from 80% to
the real per-module numbers
The CI comment and README both claimed a flat 80% line-coverage floor, but
kover { reports { verify } } in each module's build.gradle.kts sets different,
higher floors: kuri and kuri-bind require 99% line coverage (85% and 88%
branch respectively), and kuri-serde-kotlinx requires 90% line / 80% branch.
80% never appears in any module's Kover config, so the documented number was
simply wrong and could mislead a contributor into expecting a build to pass
well below what koverVerify actually enforces.
Closes #91
---
.github/workflows/ci.yml | 5 +++--
README.md | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index ae79402..39884f2 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -83,8 +83,9 @@ jobs:
key: ${{ runner.os }}-configcache-gate-${{ hashFiles('**/*.gradle.kts', 'gradle.properties', 'gradle/libs.versions.toml', 'gradle/wrapper/gradle-wrapper.properties') }}
restore-keys: ${{ runner.os }}-configcache-gate-
- name: ktlint, detekt, and JVM coverage floor
- # koverVerify pulls in jvmTest and enforces the 80% line-coverage rule. Piped through
- # tee/grep (pipefail is on by default for `shell: bash`, so a gradlew failure still
+ # koverVerify pulls in jvmTest and enforces each module's line/branch floors: kuri and
+ # kuri-bind at 99% line / 85% and 88% branch respectively, kuri-serde-kotlinx at 90%
+ # line / 80% branch (see each module's build.gradle.kts kover block). Piped through
# fails the step) to surface Gradle's own configuration-cache hit/miss line in the job
# summary — otherwise confirming the cache above is doing anything means digging
# through the raw --stacktrace log by hand.
diff --git a/README.md b/README.md
index 5187471..ecbed65 100644
--- a/README.md
+++ b/README.md
@@ -13,7 +13,7 @@
-
+
## Contents
@@ -592,7 +592,8 @@ Building kuri requires a JDK 21 toolchain; the bundled Gradle wrapper provisions
- Kotlin `allWarningsAsErrors`
- explicit-API strict mode
- the binary-compatibility validator (`apiCheck`)
-- an 80% Kover line-coverage floor
+- per-module Kover line/branch floors: `kuri` and `kuri-bind` at 99% line / 85% and 88% branch
+ respectively, `kuri-serde-kotlinx` at 90% line / 80% branch
After an intentional public-API change, regenerate and commit the API snapshot in the same change:
From 1294a0c6f086cd57010111bc274e1b05c8bc531d Mon Sep 17 00:00:00 2001
From: OmarAlJarrah
Date: Sun, 19 Jul 2026 14:44:12 +0300
Subject: [PATCH 2/2] docs: restore dropped tee/grep pipefail note in the
coverage-floor CI comment
The coverage-floor comment rewrite accidentally deleted the clause explaining
why the gradlew invocation is piped through tee/grep, leaving a broken fragment
("Piped through fails the step)") with a dangling parenthesis. Restore the
"tee/grep (pipefail is on by default ..." line so the comment reads coherently
again.
---
.github/workflows/ci.yml | 1 +
1 file changed, 1 insertion(+)
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 39884f2..3a7e437 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -86,6 +86,7 @@ jobs:
# koverVerify pulls in jvmTest and enforces each module's line/branch floors: kuri and
# kuri-bind at 99% line / 85% and 88% branch respectively, kuri-serde-kotlinx at 90%
# line / 80% branch (see each module's build.gradle.kts kover block). Piped through
+ # tee/grep (pipefail is on by default for `shell: bash`, so a gradlew failure still
# fails the step) to surface Gradle's own configuration-cache hit/miss line in the job
# summary — otherwise confirming the cache above is doing anything means digging
# through the raw --stacktrace log by hand.