-
Notifications
You must be signed in to change notification settings - Fork 2
Add coverage #11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add coverage #11
Conversation
Note Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported. |
Reviewer's GuideIntroduces a new GitHub Actions workflow to automatically collect Rust coverage data with cargo-llvm-cov and submit it to Coveralls on every push and pull request. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Warning Rate limit exceeded@kaidokert has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 4 minutes and 44 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughA new GitHub Actions workflow named "Coverage" has been added. It runs on all branches for push and pull request events, sets up Rust with coverage tools, generates code coverage data using cargo-llvm-cov, and uploads the results to Coveralls. No code or public API changes were made. Changes
Poem
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. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @kaidokert - I've reviewed your changes and they look great!
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/coverage.yml (1)
33-34
: Patch-level pin deviates from repo conventionYou usually pin actions to major tags to pick up safe patch updates automatically.
coverallsapp/github-action@v2.3.6
is frozen to an exact patch; consider relaxing it:- uses: coverallsapp/github-action@v2.3.6 + uses: coverallsapp/github-action@v2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/coverage.yml
(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: kaidokert
PR: kaidokert/picojson-rs#1
File: .github/workflows/build.yaml:0-0
Timestamp: 2025-06-28T23:51:07.640Z
Learning: In GitHub Actions workflows, kaidokert prefers to pin actions to major version tags (e.g., @v1) rather than specific versions, as they automatically resolve to the latest patch/minor versions within that major version, providing both stability and automatic updates.
🔇 Additional comments (2)
.github/workflows/coverage.yml (2)
3-9
: Possible double execution on every PR
push
+pull_request
on the same branch glob means the workflow fires twice for every PR coming from a branch in the same repo (once for the push that updates the branch and once for the PR event).
Coveralls will then receive two uploads, which can confuse status checks and distort coverage history.If you don’t need both, keep only
pull_request
or add a conditional, e.g.if: github.event_name == 'push' && github.event.ref != 'refs/heads/${{ github.event.pull_request.head.ref }}'
29-31
: Ensure full workspace coverage & cache build to speed up runs
- If the repo is a Cargo workspace, add
--workspace
so you don’t miss member crates:- cargo llvm-cov --lcov --output-path lcov.info + cargo llvm-cov --workspace --lcov --output-path lcov.info
- Consider adding an
actions/cache@v3
step for~/.cargo
andtarget
to cut runtime by ~50 %.
Summary by Sourcery
CI:
Summary by CodeRabbit