Update: I have now tested with dry-run and enabled a separate branch_9x run for RenovateBot / SolrBot. So be prepared for a storm of PRs for branch_9x.
This will be quite valuable as the gradle version catalog in main makes cherry-picking to 9x hard. Besides, 9.x has dependencies that main does not and vice versa, so we'll now be in better shape for making sure future 9.x releases have up-to-date dependencies. > Renovatebot, I'll definitely take a closer look, especially to see how > it handles security updates. Once we start publishing our dependency graph to GitHub, Renovatebot can take advantage of that and file special vulnerability PRs with a custom label, see https://docs.renovatebot.com/configuration-options/#vulnerabilityalerts Jan > 30. juli 2025 kl. 13:27 skrev Eric Pugh <de...@yahoo.com.INVALID>: > > 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 >
