Conversation
Keep wrapper upgrades out of dependency batches and leave them to the existing dedicated workflow. Ignore the wrapper in root, examples, and smoke-test entries, including scans of the root composite build.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughDependabot now ignores ChangesGradle Wrapper Update Coordination
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~3 minutes Change: Other Suggested reviewers: Merge Risk: ⚪ Minimal · up to This configuration change keeps wrapper upgrades on the dedicated workflow without introducing an established runtime or delivery risk. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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 |
Exclude
gradle-wrapperfrom Dependabot updates so Gradle upgrades do not enter the general dependency batch, as happened in #12067. Wrapper upgrades remain handled by the existing dedicated Update Gradle Wrapper workflow.Add the exclusion to the root, examples, and smoke-test entries. The examples and smoke-test builds include the root build, so their scans also discover its wrapper. Existing dependency exclusions and the dedicated workflow remain unchanged.
Summary by CodeRabbit