Conversation
WalkthroughUpdates CI to generate both XML and HTML coverage reports in a single step. Adds Kover report configuration in Gradle Kotlin DSL with global and total filters placeholders; existing verification threshold remains unchanged. No runtime or public API changes. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
|
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferences |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #62 +/- ##
=======================================
Coverage 88.88% 88.88%
=======================================
Files 2 2
Lines 9 9
Branches 1 1
=======================================
Hits 8 8
Misses 1 1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
build.gradle.kts (1)
120-139: Fill Kover filters with concrete class/package patterns (avoid file globs).The placeholders are fine for WIP, but Kover’s filters expect class/package names (FQNs), not file-system globs. Providing concrete examples now will prevent misconfiguration later and make intent explicit.
Consider something like the following within the existing blocks:
kover { reports { filters { - excludes { - // exclusions for all report variants - } - includes { - // inclusions for all report variants - } + excludes { + // exclusions for all report variants + // by packages: + packages("dev.shtanko.generated.*", "dev.shtanko.example.*") + // by classes (FQCNs with simple patterns): + classes("*.BuildConfig", "*.R", "*.R$*") + // by annotations: + // annotatedBy("kotlinx.serialization.Serializable") + } + includes { + // inclusions for all report variants + // packages("dev.shtanko.core.*", "dev.shtanko.feature.*") + // classes("dev.shtanko.*Service", "dev.shtanko.*UseCase") + } } total { // overriding filters only for total report filters { - excludes { - // exclusions only for total report - } - includes { - // inclusions only for total report - } + excludes { + // exclusions only for total report + // packages("dev.shtanko.integration.*") + } + includes { + // inclusions only for total report + // packages("dev.shtanko.*") + } } } } }If you prefer path-based excludes (e.g., generated sources), keep those in tooling like ktlint/spotless or Gradle source sets, not in Kover filters.
If you’d like, I can propose a first-pass filter set based on common Kotlin/JVM conventions..github/workflows/ci.yml (2)
72-74: Good: generate both Kover XML and HTML in one step; consider renaming step and making it more robust.Minor nit: The step name still mentions “Xml,” but you now generate HTML too. Also consider adding
--no-daemon --stacktracefor consistency with other steps.Potential tweak:
- Rename step to “Generate Kover coverage reports (XML + HTML)”.
- Command:
./gradlew koverXmlReport koverHtmlReport --no-daemon --stacktrace.If you want PR reviewers to access the HTML report easily, upload it as an artifact:
- name: Upload Kover HTML coverage report uses: actions/upload-artifact@v4 with: name: kover-html-report path: build/reports/kover/html
72-74: Decide on a single source for coverage uploads (Kover vs JaCoCo) to avoid drift.You’re now producing Kover XML/HTML, Codecov already consumes Kover XML, but Coveralls/Codacy steps still point to JaCoCo XML. That’s fine if intentional, but maintaining two sources can diverge.
- If you intend to standardize on Kover everywhere, update Coveralls/Codacy to use
./build/reports/kover/report.xml.- If Coveralls/Codacy require JaCoCo XML specifically, keep as-is.
Would you like me to prepare a PR-ready diff to switch Coveralls/Codacy to Kover XML (if compatible with your tooling)?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
.github/workflows/ci.yml(1 hunks)build.gradle.kts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Build
🔇 Additional comments (1)
build.gradle.kts (1)
120-139: Kover plugin is applied at root only; no subprojects detectedThe scan shows a single
build.gradle.kts(at the repo root) withalias(libs.plugins.kover)on line 28 and no other Gradle Kotlin or Groovy build files in subdirectories. Since there are no subprojects’ build scripts, the concern about applying Kover per-module does not apply here.Likely an incorrect or invalid review comment.
2 participants
Summary by CodeRabbit