It would be a huge win to better handle the simple dependency updates with minimal human intervention. I am somewhat overwhelmed by the number of notifications and it’s hard to distinguish the rote ones from the important ones.
I chatted w Jason G the other day about the feasibility of letting certain updates go through a automated process to get merged. Maybe start with only patch version changes that pass all tests and then are merged to build confidence in our approach? I like learning from other projects too!! Sent from my iPhone > On Jul 30, 2025, at 4:41 AM, Piotr P. Karwasz <pi...@mailing.copernik.eu> > wrote: > > Hi Jan, > >> On 28.07.2025 00:11, Jan Høydahl wrote: >> Dependabot is a public bot and deems it unsafe to execute custom >> scripts, so it is not supported. That’s why we run our own bot without >> such restrictions. > > In Apache Logging, we've managed to work around this limitation by using > GitHub Actions on Dependabot PRs to tailor them to our needs: for > example, by automatically adding changelog entries for each update. I > believe a similar setup could be adapted for Apache Solr as well. > > We currently have a workflow that runs on `pull_request_target` (yes, > not ideal), but we've also developed a new prototype [1] with a safer > and more flexible design: > > - Metadata gathering workflow: A wrapper around > `dependabot/fetch-metadata` that runs on `pull_request`. It supports > grouped updates and might even be shareable across ASF projects. It also > exposes valuable metadata, including information on fixed security > vulnerabilities. > - Privileged workflow: Uses the gathered metadata to perform actions > needed to align the PR with project requirements. > > For Solr, this could include: > - Opening a corresponding JIRA issue > - Renaming the Dependabot PR > - Applying Gradle-specific modifications directly to the PR > > One clear advantage of Dependabot is that projects don't need to > maintain their own GitHub App or bot infrastructure. I'm currently > arranging a meeting with the Dependabot team, happy to schedule it for > when you're back from vacation if you're interested. > > >> Wrt separate dep PRs for 9.x, I have submitted fixes to renovatebot >> to support this even for forked mode. Need to test it. But currently on >> holiday so won’t be for another couple weeks. > > Enjoy your vacation! > > While I slightly prefer MIT-licensed Dependabot over AGPL-licensed > Renovatebot, I'll definitely take a closer look, especially to see how > it handles security updates. > > Speaking of which, I was recently pointed to SecObserve [2], a > lesser-known but quite capable Python-based vulnerability management > system. It has broad integration support and can be configured to > respond directly to GitHub Dependabot Alerts, avoiding the need to > surface security updates in public PRs. > > To remove *publicly disclosed* vulnerabilities in the dependencies of > Apache Solr, secrecy is not an issue, but it is a choice the PMC can > always make. > > Piotr > > References: > [1] https://github.com/apache/logging-parent/pull/419 > [2] https://github.com/MaibornWolff/SecObserve > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
