Incredible! Sent from my iPhone > On Aug 29, 2025, at 8:04 AM, Jan Høydahl <jan....@cominvent.com> wrote: > > 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 >> >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
