fix: use govulncheck -scan=module for library CI#33
Conversation
Libraries should scan dependencies, not stdlib — the stdlib version is the consumer's choice. -scan=module checks only go.mod deps.
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 23 minutes and 21 seconds. ⌛ 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. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Pull request overview
Adjusts the vulnerability scanning step in CI linting to scan only module dependencies (go.mod) rather than also scanning the Go stdlib, aligning the scan with library ownership/responsibility.
Changes:
- Update
make lintto rungovulncheckwith-scan=moduleinstead of scanning./....
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Summary
govulncheck -scan=moduleinstead ofgovulncheck ./...in CILibraries should scan dependencies (go.mod), not stdlib — the stdlib version is the consumer's choice, not the library's.
-scan=modulechecks only dependency vulnerabilities, avoiding false failures when the CI Go toolchain has unfixed stdlib CVEs.Test plan
make lintpasses locally