Repository navigation
chore: pin relayer-utils and zk-regex-apis to immutable refs - #4
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe Cargo manifest pins ChangesDependency source pinning
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Other Merge Risk: ⚪ Minimal · up to The dependency sources are pinned to the intended resolved revisions, with no identified merge-blocking risk. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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
This crate requests
zk-regex-apisfromzkemail/zk-regexatbranch = "main", and so does therelayer-utilsrevision it is locked to. zk-regex#92 removes that crate frommain. The committedCargo.lockkeeps working, but any re-resolve would break.What
relayer-utilstofcd5333, the revision already inCargo.lock. Tracking itsmainwould otherwise pull in a much newer, incompatible API on the next update.[patch]that redirects everyzk-regex-apisrequest, direct and transitive, to tag2.1.0. That is commit491a2dc, the one already locked. The double slash in the patch URL is deliberate, Cargo refuses a patch that points to the same source it replaces.No resolved commit changes. The lockfile diff is two
sourcestrings, plus the lockfile format going from v3 to v4, which needs Cargo 1.78 or newer.I used
2.1.0instead of2.1.3on purpose, so the code being built stays byte-identical.Verification
cargo metadata --lockedresolves with a singlezk-regex-apisentry. No build was run because no source changed.Summary by CodeRabbit