chore(deps): keep cargo updates that cannot resolve out of the non-major Renovate group (LAB-6633) - #91
Conversation
getrandom 0.3 removed the js feature. The direct 0.2 entry exists to turn that feature on for the getrandom 0.2 copy that ring and rand_core also use on wasm32, so a bump past 0.2 fails the Cargo.lock update and blocks every other update in the all-minor-patch group. Take such an update out of the group and hold it under Pending Approval on the Dependency Dashboard. Vulnerability updates are not held: Renovate forces dependencyDashboardApproval off for them. Patch updates within 0.2 stay in the group.
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Warning Review limit reachedNext included review available in 36 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Repository: cachekit-io/cachekit-core/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: cachekit-io/cachekit-core/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughThe Renovate configuration adds a Cargo package rule for minor and major Changesgetrandom update configuration
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~5 minutes Change: Other Merge Risk: ⚪ Minimal · up to Routine getrandom minor and major upgrades require dashboard approval while patch grouping and vulnerability remediation remain unaffected; no material merge blocker is indicated. Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to The change is narrowly scoped to routine getrandom minor and major updates. It does not update application dependencies or add credentials or privileges. Available evidence supports preserving vulnerability-remediation updates, but the deployed approval and retry behavior has not been independently verified. Retained concerns Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
🚥 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 |
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
27Bslash6
changed the title
![kodus-27b[bot]](https://avatars.githubusercontent.com/u/223823690?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Cargo treats a 0.x minor bump as semver-incompatible, but Renovate classes it as minor and puts it in the all-minor-patch group. Holding getrandom was not enough: reqwest 0.12 to 0.13 removed the rustls-tls feature and fails the same Cargo.lock update, and other 0.x bumps in the group raise rust-version past 1.85 or change APIs. Give every cargo 0.x minor update its own PR so one breaking bump no longer blocks the routine ones. 0.x patch updates stay in the group; the getrandom hold stays on top.
3ca9293
27Bslash6
changed the title
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
crypto-common 0.1 pins generic-array to exactly 0.14.7, so Renovate's 0.14.9 lock file update cannot resolve. Renovate runs every lock file update in a group as one cargo chain, so this one failure would fail the whole all-minor-patch group. Hold it under Pending Approval instead.
27Bslash6
changed the title
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
1 participant
Renovate's
all-minor-patchgroup has failed itsCargo.lockupdate since 2026-09-28, so no routine Rust update lands. This adds threepackageRulestorenovate.jsonso one update that cannot resolve no longer blocks the rest of the group.Why the group breaks. Today's group bumps
getrandomfrom0.2to0.4and keepsfeatures = ["js"]. getrandom 0.3 removed that feature, socargo updatefails:That failure hides two more. Cargo treats a 0.x minor bump (
0.12to0.14) as semver-incompatible, but Renovate classes it asminorand groups it. Withgetrandomleft at 0.2, the group resolves but fails CI:aes0.9.3 requires rustc 1.89, above this crate's 1.85rust-version. Thesha2/aes-gcmbumps also leave[dev-dependencies]on 0.10, because dev-dependencies go to a separate group, so the test build sees twosha2crates (E0464). Also,crypto-common0.1 pinsgeneric-arrayto exactly0.14.7, so the group'sgeneric-array0.14.9 lock file update cannot resolve either. Renovate runs every lock file update in a group as onecargo update --precisechain, so any one failure fails the whole group.Rule 1: cargo 0.x minor updates get their own PR (
matchCurrentVersion: "<1.0.0",matchUpdateTypes: ["minor"],groupName: null). 0.x patch updates stay in the group. A crate's normal and dev-dependency bumps now share one branch,renovate/<crate>-0.x, so they move together.Rule 2: hold
getrandomat 0.2.ring0.17 andrand_core0.6 still depend on getrandom 0.2, and the direct0.2entry is what turns onjsfor that 0.2 copy on wasm32. Cargo unifies features per version, so a direct0.4entry would leave the 0.2 copy without it.Rule 3: hold
generic-array0.14 patch updates until nothing depends oncrypto-common0.1.Rules 2 and 3 set
groupName: nullanddependencyDashboardApproval: true, so the update waits under Pending Approval on the Dependency Dashboard and no branch opens for it. Vulnerability updates are not held, because Renovate forcesdependencyDashboardApprovaloff for them. No rule setsallowedVersions: Renovate does not override that key for vulnerability updates, so it would silence them.Checked with Renovate 43.288.0. The shared preset and this file were merged the way Renovate merges
extends, deps were extracted from this repo'sCargo.tomlandCargo.lockby Renovate's cargo extractor, and each case ran through Renovate's ownbranchifyUpgrades:maingetrandom0.2 → 0.4 (minor)renovate/all-minor-patch, not heldrenovate/getrandom-0.x, heldserdeminor, same runrenovate/all-minor-patchrenovate/all-minor-patch, not heldserdepatchrenovate/all-minor-patchrenovate/all-minor-patch, not heldgetrandomvulnerability update (GitHub alert and OSV)renovate/crate-getrandom-vulnerability, not heldgetrandom0.2.x patchrenovate/all-minor-patchrenovate/all-minor-patchlz4_flex0.12 → 0.13 (minor)renovate/all-minor-patchrenovate/lz4_flex-0.x, not heldlz4_flex0.12.x patchrenovate/all-minor-patchrenovate/all-minor-patchsha20.10 → 0.11, normal + dev dependencyrenovate/all-minor-patchandrenovate/rust-dev-depsrenovate/sha2-0.xgeneric-array0.14.7 → 0.14.9renovate/all-minor-patchgeneric-arrayvulnerability updateA
--platform=local --dry-run=lookuprun against crates.io agrees. On this branchrenovate/all-minor-patchholds only thethiserror,serde,xxhash-rust,zeroizeandcbindgenlock file updates.lz4_flex,hkdf,sha2,hmac,aes-gcm,aes,blake2andcriterioneach get their own branch, andgetrandomandgeneric-arraywait for approval. Those five lock file updates, applied by hand withcargo update --precise, resolve and pass fmt, clippy, the stable and 1.85 test suites andcargo audit.renovate-config-validator --strict --no-global renovate.jsonpasses.This fixes the lock file update, not every check. The regenerated group will still fail
cargo denyandcargo vet.thiserror2.0.21 andserde1.0.229 pull insyn3 next tosyn2, andcbindgen0.29.4 adds a secondwindows-sys, both of whichmultiple-versions = "deny"rejects. The new versions are also not yet vetted. Those are separate changes.Summary
Adds a Renovate
packageRulesentry that removesgeneric-arraypatch updates from the non-major update group and requires manual approval via the Dependency Dashboard.Changes
renovate.json: new rule scoped to:matchManagers:cargomatchPackageNames:generic-arraymatchUpdateTypes:patchgroupName: null: excludes these updates from the grouped non-major PR.dependencyDashboardApproval: true: updates wait under "Pending Approval" on the Dependency Dashboard.Rationale
crypto-common0.1, a dependency of the RustCrypto 0.10 crates, pinsgeneric-arrayto exactly0.14.7. Any other0.14.xpatch bump fails theCargo.lockupdate. Because the bump is grouped with the other non-major updates, that failure blocks the entire group. Holdinggeneric-arrayseparately lets the rest of the group proceed.Notes
Cargo.lockdepends oncrypto-common0.1.