-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Renovate proposal #29
Conversation
Hi @lmilbaum thank you for the proposal. Maybe you could edit the proposal and highlight that this would replace Dependabot which is included with GitHub and currently in use? Also, it would be worth mentioning why we would pick this over Dependabot, and what the management overhead is (we need to allow an app, someone needs to go register an account with them or self-host, etc). Thanks! |
Thank you for your feedback. I've just noticed that the section which emphasizes the advantages was missing. |
Perhaps also add some link to |
Done. |
a0313aa
to
1ea78c7
Compare
I help maintain Renovate bot's documentation, so obviously I like Renovate bot. 😉 Why pick Renovate?Copy/paste from the Renovate docs homepage:
Killer features
Here's the Dependency Dashboard in action: Management overhead?
The overhead depends on how you're going to run Renovate. You can:
Easiest way to get startedThe easiest way to run the bot is by installing it as a GitHub-hosted app. 5 You can select what repositories you want Renovate to access after installing the app if you don't want Renovate to run on all your repositories. Footnotes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments on the proposal text.
|
||
While Renovate can be a powerful tool for automating dependency updates, there are a few potential drawbacks to consider: | ||
|
||
1. Pull request overload: Renovate can generate a large number of pull requests, especially if you have many repositories or dependencies. This can create a lot of noise in your pull request feed and may require additional effort to manage. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can reduce the pull request overload by:
- setting a schedule for updates (say get
foo
updates on the first day of the week) - using the Dependency Dashboard Approval Workflow, where you only get updates when you request them from the dashboard. I recommend you only use this to get you back up to date on your terms, once you're nearly/fully up to date, let Renovate create PRs again!
- using automerge to merge after tests pass, can be helpful for things like Prettier/ESLint/Standard
- setting a custom
prConcurrentLimit
1, the default is max 10 open PRs at once - edit: Renovate also rate-limits creating PRs, the default is
2
PRs created per hour
Footnotes
|
||
2. False positives: Renovate may sometimes generate pull requests for updates that don't actually improve your dependencies or may introduce new issues. This can create additional work and may require manual intervention to resolve. | ||
|
||
3. Configurability complexity: While Renovate offers a lot of configuration options, this can also make it more complex to set up and manage than other dependency update tools. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend you start with config:base
1 and tune things after getting some experience with the default behavior.
Footnotes
|
||
3. Configurability complexity: While Renovate offers a lot of configuration options, this can also make it more complex to set up and manage than other dependency update tools. | ||
|
||
4. Limited control over updates: Renovate automates the update process, but you may not have full control over which updates are applied to your dependencies. This can be a concern if you need to ensure strict compatibility or stability with certain packages or versions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use the Dependency Dashboard, and use packageRules
to group "must update together packages" to get more control.
|
||
4. Limited control over updates: Renovate automates the update process, but you may not have full control over which updates are applied to your dependencies. This can be a concern if you need to ensure strict compatibility or stability with certain packages or versions. | ||
|
||
5. Potential conflicts with other automation: If you have other automation tools or processes in place that also manage dependency updates, Renovate may conflict with them and create additional work or confusion. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not run Dependabot and Renovate together, you'll end up with a mess of open PRs.
If you want to get vulnerabilityAlerts
1 then you'll need to enable the "Dependency Graph" and "Dependabot Alerts". You still keep the "normal Dependabot" disabled though!
Footnotes
@lmilbaum thank you very much again for your presentation. As discussed, let's keep this proposal as a draft until we have a demo of running Renovate as a GitHub Actions periodic job. |
@HonkingGoose thank you very much for your input, we'll hopefully move forward with this proposal in 2-3 weeks. |
Hey folks, can you please remove my review request from this PR? It seems I don't have the ability to. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the currently maintained projects, this seems to me to be extra work.
I think this would make sense as an option for projects, but not the default. But that could lead to more fragmentation.
This would make more sense if we switched off of GitHub.
I understand your concern. If that may help, my team (platform engineering) will own the on-boarding process and maintenance. |
Per today's discussion, we are going to have a look at this functionality as a prototype using a repo or two from the Arcalot org. Seeing directly how this change affects our maintenance workflows and helps us will be useful to better inform the decision here. |
We have implemented a prototype of this implementation with one plugin repo that has open dependabot PRs so that we can see a live comparison against Renovate. I invite the Round Table members to please have a look at the open PRs for this repo to see what Renovate offers us: https://github.com/arcalot/arcaflow-plugin-aws-ec2-control/pulls Implementing this required allowing the platform-engineering-bot write access to the repo, and a Renovate configuration file to be added: https://github.com/arcalot/arcaflow-plugin-aws-ec2-control/blob/main/renovate.json So the impact for implementation across the org is low, and we can do it in a phased way if this proposal is approved. I believe we would grant the platform-engineering-bot write access at the org level, and then add this config to each repo for which we want to enable Renovate. Based on the conversations and this update, I am resetting the votes on this proposal and adjusting the voting period to 14 days, targeted to end on Wednesday, July 19, or when quorum is reached, whichever comes first. |
I would def like to see this with all the build issues fixed manually before dependabot gives this a go. It seems we have had different breaks within the last week or so. |
I had the same thought. I'll try to fix the builds and then let the dependabot and renovate PRs rebase. |
Merging as approved with a quorum of votes from the ART |
Changes introduced with this PR
Please explain your changes here.
By contributing to this repository, I agree to the contribution guidelines.