LCORE- Update checkout action to v7#2129
Conversation
This addresses a bug where a test run triggered by a tag would fail.
|
Warning Review limit reached
Next review available in: 43 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: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (4)
WalkthroughSix GitHub Actions workflows upgrade checkout steps to ChangesGitHub Actions checkout configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 7✅ Passed checks (7 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
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 |
This is not ideal but is equivalent to what is happening with the v4 version of the action today. Explicit opt-it is required in v7. Actions using pull_request_target that are running code from PRs from forks should be reevaluated so that tests can run without the risk of compromising the repository.
aa0a855 to
18bb240
Compare
Description
Update
actions/checkoutto v7 in all cases. This addresses a bug where a job triggered by a tag would fail, which is what caused the 0.6.0 job run to fail.This brings to light a risky configuration that exists currently. Jobs that are triggered by
pull_request_targetare running code from PRs from forks because access to secrets is needed for the tests to run. This is a common scenario but carries risk. It is possible to do this securely. That will require refactoring how the tests run to separate the parts that need access to secrets from code submitted in PRs from forks.Once this is merged to
main, it will need to be back port to all release branches. Then we need to do two things:pull_request_targetrun as expected.Unfortunately there is no way to re-run the job to publish 0.6.0 since it contains the old version of the action with the bug. We will have to manually build and publish that image if we want it to exist in https://quay.io/repository/lightspeed-core/lightspeed-stack, or publish a new tag. Fix it forward, as they say.
Type of change
Tools used to create PR
Related Tickets & Documents
None
Checklist before requesting a review
Testing
main. I simulated this by creating a fork of my fork, duplicating the failure, then running again with the changes in this PR merged tomainin my fork.Summary by CodeRabbit