ci(snyk): run Snyk weekly via scheduled caller, not per-PR#233
Conversation
Snyk hosted tests are metered (the org plan caps the monthly test count), so invoking python-snyk.yml + python-snyk-iac.yml from per-PR self-test.yml exhausted the quota. Move both behind a dedicated weekly scheduled caller, mirroring the sbom-nightly.yml pattern. - Add snyk-weekly.yml: schedule (Mon 03:43 UTC) + workflow_dispatch caller for python-snyk.yml and python-snyk-iac.yml; same security-events:write permission contract as sbom-nightly.yml. - Remove test-python-snyk and test-python-snyk-iac jobs from self-test.yml so pull requests no longer trigger metered Snyk scans. - Document the weekly-schedule (not pull_request) convention in both reusables' usage headers for downstream callers that opt into run-snyk: true. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 28 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
✨ 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 |
|



Why
Snyk hosted tests are metered: the org plan caps the monthly test count, and the limit was being exhausted. The in-code per-PR driver was
self-test.yml, which invokedpython-snyk.yml+python-snyk-iac.ymlwith the realSNYK_TOKENon every push and PR touching a workflow file.run-snykalready defaultsfalseinpython-standard-stack.ymland no consumer repo opts in, so this self-test path was the only in-code per-PR Snyk consumer.What
Move Snyk to a weekly schedule, mirroring the established
sbom-nightly.ymlpattern (SBOM is deliberately kept out of per-PR self-test and runs only via its scheduled caller).snyk-weekly.yml—schedule(Mon 03:43 UTC, off-peak/non-:00, offset from sbom-nightly and dependency-provenance-weekly) +workflow_dispatch. Single scheduled entry point for both Snyk reusables, with the samecontents: read+security-events: writepermission contract assbom-nightly.yml.test-python-snykandtest-python-snyk-iacfromself-test.yml— pull requests no longer trigger metered Snyk scans. A maintainer changing either reusable validates via the new caller'sworkflow_dispatch.run-snyk: trueshould wire Snyk onschedule:, notpull_request:.Verification
actionlint .github/workflows/snyk-weekly.ymlclean; all four touched workflows parse.uses:.*python-snykinvocation remains inself-test.yml.Note (out of scope, separate surface)
The 200-tests/month exhaustion ("docker and open source tests") is most likely dominated by the Snyk SCM/GitHub-App integration posting a PR check per imported target (williaby has ~36 targets), which is an org-level Snyk setting, not workflow code. This PR fixes the code surface; disabling the integration's per-PR checks (and relying on Snyk's recurring scheduled scan) is a follow-up in the Snyk UI/API.
Generated with Claude Code