fix: use govulncheck -scan=module for library CI#32
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 37 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
Updates the CI lint step to run govulncheck in module-scanning mode so the library’s vulnerability checks focus on dependency versions (go.mod) rather than the Go toolchain’s stdlib.
Changes:
- Switch
govulncheckinvocation inmake lintfrom./...scanning to-scan=module.
💡 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