chore: Renovate config - #155
Conversation
|
Warning Review limit reached
Next review available in: 48 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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. 📝 WalkthroughWalkthroughThe Renovate configuration replaces the recommended preset with community presets and defines rules for patch, digest, major, minor, and Rust updates. The rules configure categories, approval behavior, auto-merge messaging, branch prefixes, and a Rust minor-update schedule. ChangesRenovate policy
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
renovate.json (1)
13-13: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueUse cron schedules instead of deprecated Later text.
Renovate’s text-based
before ... on ...syntax is deprecated in favor of five-part cron. Convert the repository’sscheduleentries from Later text to cron ifWeekdaymeans Monday–Friday.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@renovate.json` at line 13, Update the schedule entry in renovate.json from deprecated Later text to a five-part cron expression representing execution before 6:00 AM on weekdays (Monday through Friday). Preserve the existing scheduling intent.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@renovate.json`:
- Line 13: Update the schedule entry in renovate.json from deprecated Later text
to a five-part cron expression representing execution before 6:00 AM on weekdays
(Monday through Friday). Preserve the existing scheduling intent.
|
Hey @thompson-tomo Thank you for your PR and the follow-up. Personally, I think the configuration file should look like this: {
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["github>open-feature/community-tooling"],
"packageRules": [
//... rust specific rules only
]
}There should not be any custom rules for GitHub actions, schedule, etc... The community has made their decisions about them. Maintaining each repository separately requires extra effort. For example, people are usually busy with work at their companies on Mondays. Applying the change in one place helps avoid unnecessary noise across multiple repositories and be consistent. If |
|
The issue i have with the community rules, is that every single update is requiring 2 approvals (1st to create, 2nd on the pr with a time delay between them). If you have 5 patches thats 10 approvals and the bigger the repo, the bigger the problem. Whereas having 1 patches pr group increases the chance of updates being approved and that pr can sit open till you are ready with new patches being added to it as time goes by. Hence this decreases work needed. I am more than open to adding some of this config to the community to help repos more efficiently maintain their dependencies. |
|
Trusted GitHub Actions would be merged without additional approvals. All other changes usually require approval from a maintainer and an owner anyway. I may also have my own opinions on this, but those decisions are made by the Governance and Technical Committees. |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@renovate.json`:
- Around line 30-34: Move the general Renovate package rule containing
dependencyDashboardCategory, dependencyDashboardFooter, and matchUpdateTypes
before the specialized CI/Docker rule. Preserve the CI/Docker rule’s later
position so its infra-specific category and footer override the general values
for matching major or minor updates.
- Around line 31-33: In renovate.json, add the missing comma after the
dependencyDashboardFooter property so matchUpdateTypes remains a separate valid
JSON property and Renovate can parse the configuration.
- Around line 9-13: Add a shared groupName to the Renovate rule containing
matchUpdateTypes for patch and digest updates, using a descriptive name so
matching updates are consolidated into one branch and pull request while
retaining the existing dashboard category and footer.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
|
I have refactored the rules to only define behaviour of rust updates. The other changes just introduce groups in the dashboard enabling 1 click to update all github actions but still raises seperate pr hence makes it easier to maintain & can be upstreamed. |
|
@thompson-tomo Do you have any great example with Renovate, Cargo and
Please remember that this is a volunteer-driven project, and people contribute in their own free time. While some companies may allow employees to contribute during working hours, that's a benefit rather than a requirement. Please follow the schedule defined in |
|
I am fully aware that the project is volunteer driven hence why i am trying to help to reduce time & effort needing to be spent on housekeeping. I fail to see anything added by the extends which will lead to more work, & it also provides more info to the dashboard about abandonments etc. The devDependencies preset i also believe is not applicable to rust so that would not cause any changes let alone more work. In relation to scheduling of minor rust updates which is all i have defined a schedule for, i will defer to @erenatas, as to your preference:
The current setup is the first but atm it applies to all update types and it also happens any day or time of the week. My preference is the first as it is less work (approvals) for maintainers and we avoid that noticeable delay between the first & second approval which would mean you need 2 review sessions. |
Signed-off-by: James Thompson <thompson.tomo@outlook.com>
Signed-off-by: James Thompson <thompson.tomo@outlook.com>
Signed-off-by: James Thompson <thompson.tomo@outlook.com>
Signed-off-by: James Thompson <thompson.tomo@outlook.com>
Signed-off-by: James Thompson <thompson.tomo@outlook.com>
Signed-off-by: James Thompson <thompson.tomo@outlook.com>
9c36522 to
faeb4e6
Compare
Hi! I appreciate the effort being put into helping manage the crates easier. I personally don't mind when PRs are generated. What would be useful for me personally is if the PRs were grouped per workspace member (or flagd provider family and other members) in repo. I only maintain flagd provider, while @erka helps out with another, there was a time where I merged an update for all workspace members and it broke other crates besides flagd provider. Since then I'm embarrassed to say I've been practically running cargo upgrade --incompatible locally (for what I'm responsible of), try to pass it, then let the renovate PRs get closed automatically. |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
renovate.json (1)
29-29: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winPrefer cron syntax for the schedule.
"before 7am on Monday"uses Renovate's deprecated Later syntax. Renovate recommends cron syntax for new schedules. Settimezoneif7ammust use a specific repository timezone. (docs.renovatebot.com)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@renovate.json` at line 29, Replace the deprecated Later-style value in the Renovate schedule configuration with equivalent cron syntax, and set an explicit timezone if the intended 7am timing depends on a specific repository timezone.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@renovate.json`:
- Around line 19-24: Update the Rust package rule identified by matchCategories:
["rust"] so patch updates are included in the intended Rust flow or
dependencyDashboardApproval is explicitly disabled for that category; preserve
the existing branch prefix and dashboard messaging settings.
- Around line 16-17: Update the Renovate configuration around
dependencyDashboardFooter and matchUpdateTypes so the dashboard text does not
claim automerge or manual-approval behavior that is not enforced locally. Use
neutral wording unless you add explicit packageRules defining the corresponding
behavior, and ensure the messaging remains consistent with the inherited preset
for all referenced update types.
---
Nitpick comments:
In `@renovate.json`:
- Line 29: Replace the deprecated Later-style value in the Renovate schedule
configuration with equivalent cron syntax, and set an explicit timezone if the
intended 7am timing depends on a specific repository timezone.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
Have kept the auto generation for minor.
Have added grouping based on parentdir to the dashboard and the brach names. This means that you will be able to trigger all flagd updates using a single click from the dashboard. This should remove the need to run it locally. |
3 participants
This PR