Switch to dependabot #1338
Switch to dependabot #1338
Conversation
Our renovate instance is maintained by a distinct entity, and seems to have been having trouble making updates lately. I looked at doing an integration via GHA, but it requires a custom token which is a bit awkward. Let's use the one builtin to GH for now. Signed-off-by: Colin Walters <[email protected]>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @cgwalters, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
Hello, gemini-code-assist here to provide a summary of this pull request. This PR aims to switch the project's dependency update automation from Renovatebot to GitHub's built-in Dependabot. The author notes that the existing Renovate instance has been experiencing issues and using Dependabot offers a simpler integration, avoiding the need for custom tokens required by other methods like GitHub Actions integrations.
Highlights
- Dependency Bot Migration: The core change is migrating from Renovatebot to Dependabot for automated dependency updates.
- Renovate Configuration Removal: The existing Renovatebot configuration file (
.renovaterc.json) has been removed. - Dependabot Configuration Added: A new Dependabot configuration file (
.github/dependabot.yml) has been added to set up the new automation. - Cargo Ecosystem Updates: Dependabot is configured to check for
cargodependency updates weekly in the root directory.
Changelog
- .github/dependabot.yml
- Added new file to configure Dependabot.
- Configured Dependabot to check for
cargoupdates weekly. - Set a limit of 6 open pull requests.
- Grouped minor and patch updates under a 'minor' group.
- .renovaterc.json
- Removed the old Renovatebot configuration file.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
A bot for deps, a weekly chore,
Renovate out, Dependabot's door.
Updates arrive,
Keep code alive,
No tokens needed anymore.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request effectively transitions the project from Renovate to GitHub's built-in Dependabot for managing dependencies. The new dependabot.yml configuration is well-structured and adopts common practices for dependency updates in a Cargo workspace. The removal of the old renovate.json is also appropriate. Overall, a good move for simplifying dependency management.
Summary of Findings
- Dependabot PR Limit and Grouping Strategy: The interaction between
open-pull-requests-limit: 6and the strategy of grouping all minor/patch updates into a single PR means that 5 PR slots remain for individual major and security updates. It's important to ensure this capacity is adequate for the project's typical update cadence to avoid deferring important updates. This was raised as a medium-severity review comment. - Dependabot Configuration: Group Naming (Low Severity - Not Commented): The group name
minorforupdate-types: [minor, patch]is functional. For potentially enhanced clarity, a more descriptive name likeall-minor-patch-updatesorbatched-minor-patchcould be considered. This was deemed low severity and not commented on directly due to review settings. - Dependabot Configuration: PR Labels (Low Severity - Not Commented): Consider adding
labels: ["dependencies", "dependabot"](or similar) to the Dependabot configuration. This can help with PR organization, filtering, and automation workflows. This was deemed low severity and not commented on directly due to review settings. - Dependabot Configuration: Commit Message Prefix (Low Severity - Not Commented): If the project adheres to Conventional Commits or a similar commit message standard, adding a
commit-message: { prefix: "chore(deps)", include: "scope" }configuration could be beneficial for consistency in the commit history. This was deemed low severity and not commented on directly due to review settings.
Merge Readiness
This pull request makes a sensible switch to Dependabot for dependency management. The configuration is generally sound. There is one medium-severity point raised regarding the open-pull-requests-limit in conjunction with the update grouping strategy. It would be beneficial to consider this point to ensure the configuration optimally meets the project's needs before merging.
As an AI, I am not authorized to approve pull requests. This decision rests with the project maintainers after reviewing this feedback and any ensuing discussion.
| open-pull-requests-limit: 6 | ||
| groups: | ||
| minor: | ||
| update-types: | ||
| - minor | ||
| - patch |
There was a problem hiding this comment.
The current configuration sets open-pull-requests-limit: 6 and groups all minor and patch updates into a single pull request. This is a good strategy to reduce PR noise. However, it means that this single grouped PR will consume one slot, leaving 5 PR slots for major version updates and security updates (which are typically opened as individual PRs by Dependabot unless specifically grouped by name).
Could you consider if this limit of 5 remaining slots is expected to be sufficient, given the number of dependencies in this workspace (I see 14 workspace members and numerous dependencies) and their typical update frequency for major versions or security patches?
Potential considerations:
- If this project frequently receives major updates for several dependencies simultaneously, or multiple security advisories, the limit of 6 total PRs might lead to some important updates being deferred until existing Dependabot PRs are merged or closed.
- If this limit proves too restrictive in practice, you might need to increase
open-pull-requests-limit.
This is a common balancing act in configuring Dependabot, and the chosen limit of 6 might be perfectly adequate. This comment is to ensure this interaction has been considered for your specific project context.
renovate.json
Outdated
There was a problem hiding this comment.
The old Renovate likely stopped working after the org change, since it's owned by a central team at RH. To use this instance, we'd probably need to ask that team to allowlist the bootc-dev org so it's scanned for updates.
Renovate does have a public instance which is available for free. There shouldn't need to be any config changes after adding the GitHub app. I onboarded ublue to Renovate and configured custom logic for managing versions in arbitrary files, so I'm quite familiar with it :)
I've also setup a self-hosted Renovate which runs in GitHub Actions about a month ago (repo).
If preferred, I'd be happy to help work through either of these options.
There was a problem hiding this comment.
Thanks for your comment! You are very likely right it's related to the org move. I've enabled the main hosted renovate on this repo.
There was a problem hiding this comment.
Cool! The inherited config seems to run Renovate weekly, so I assume on Monday there will be a bunch of dependency updates.
If not, I can take a look and see what's happening.
There was a problem hiding this comment.
That said I do like the flexibility of renovate, so if you have any idea how to debug this, happy to take another try at it at some point.
I also may just need to get over the app permissions.
|
OK we never got any updates from renovate, and it's not clear to me why. The problem with the globally hosted version is I can't figure out how to debug why it's not working. The self-hosted options...well, I don't like needing to use a personal access token, and the GitHub App route is fairly heavyweight. I also don't like how the app needs write access to all the repo contents (and checks, and other things) when really all it should need is at most writes to issues (hmm may be that permissions aren't that fine grained) and the ability to make and update PRs that it submitted. Since our needs are simple right now, let's go with dependabot. |
|
FYI - if you did want to go down the self-hosted Renovate option, it's not overly complex. I even talked Jorge through the GitHub App configuration. Write permissions are needed to be able to create PRs since Renovate doesn't (by default) use forks, however you can require PRs for all changes to the main branch through repository rulesets for added security (I hope this is setup anyway 😉). The entirity of UBlue's self-hosted Renovate config is in this repo. It runs from within GitHub Actions, with no added cost or external infrastructure except for GitHub App credentials. My best guess as to why things aren't working is either the existing PR created when self-hosted Renovate was still in use is blocking new PRs from being created as the branch hasn't been deleted, or the inherited configuration this repo pulls in is trying to set something only self-hosted Renovate supports. The developer portal would be a good place to look for logs or error messages to help identify what's happening. But as you said, all this repo needs is simple update PRs, so Dependabot would work fine. It turns out Renovate is working! It doesn't have permissions to change the PR description, but has been keeping this PR up-to-date with dependency updates. |
Oh man, I just missed that because I didn't notice the change from platform-engineering-bot to renovate. Thanks! Will try a bit harder to keep renovate... |
Our renovate instance is maintained by a distinct entity, and seems to have been having trouble making updates lately.
I looked at doing an integration via GHA, but it requires a custom token which is a bit awkward.
Let's use the one builtin to GH for now.