-
Notifications
You must be signed in to change notification settings - Fork 765
Enable renovatebot for the project #1375
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
Conversation
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.
Here are some comments on the suggested config. The reference guide for how to configure the bot is here https://docs.renovatebot.com
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
We now got a private repo I'll invite a number of you to the https://github.com/solrbot/renovate-github-action repo so you can commit directly. |
* Add assertion with more details on failure
Add an hourly limit of 5, for slower on-boarding of PRs Add stability requirement of 5 days since release of a version before PR creation
Who controls that email address?
Oh god! Of all the bad ideas in the world, why am I seeing several of the worst ones here in this single issue? IMO, this separate GH account (solrbot) is outside the purview of Apache Solr project, and is a 3rd party project. We shouldn't need the private@ or PMC level involvement for this project. If you disagree, let us discuss in the private@ list about it. |
After conclusion from private@ list discussion, we don't need this bot / github action to be under official control of the Solr PMC. So I'll re-brand this project as being a 3rd party community project, both in this PR and over in the solrbot account. That means I'm reverting back 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.
Really nice docs, as usual @janhoy ! I am very much looking forward to this experiment on reducing upgrade workload... If it works, I'm going to start doing this on other opensource projects that I steward....
Group httpcomponents in same PR Check test deps montly instead of weekly
…he 3rd party bot github action repo.
…dependencies' label to PRs
Turns out the bot account needs "triage" rights on the repo in order to set the "dependencies" label on PRs. ASF.yaml provides a way to grant that. However, since we currently don't use labels at all for our PRs, I'll instead skip the |
Thanks for weighing in, now let's see the first PRs flowing in :) |
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.
This is awesome Jan, thanks for the work and great documentation!!
"dependencyDashboard": false, | ||
"enabledManagers": ["gradle"], | ||
"includePaths": ["versions.*", "build.gradle"], | ||
"postUpgradeTasks": { |
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.
This is great, and a step that's missing in the dependabot feature for the solr-operator.
This PR adds automatic dependency housekeeping to the project through Renovatebot, which is an alternative to dependabot. See slack discussion here.
So once this is merged, a self-hosted bot called SolrBot, will kick off every Sunday and file PRs for dependencies that need upgrades. Here is an example of such a PR from my sandbox test project. A nice feature is that the PR will also include changes from
gradlew updateLicenses
and--write-locks
, so for a majority of upgrades, there's nothing left to do for the committer.We can't use Dependabot since it does not support our gradle "consistent-versions" plugin. We can't use the public Renovatebot github app since it cannot be configured to run custom post-commands like
gradlew updateLicenses
. So we follow GitHub's advice of creating a custom github account for the bot, and that user will run renovatebot in a GitHub Action, and fork the solr repo and file PRs against the Solr repo. This has the nice property that the bot won't need commit-rights to the solr-repo, which would be disallowed by ASF policy.I plan to share the github credentials for the SolrBot account with the PMC if I can find a secure way of doing it. I remember there is a private svn repo per PMC, but could not find it.