Hi Jan, On 3.09.2025 00:34, Jan Høydahl wrote: >> Would it be possible to add metadata to such PRs? For example, >> using the `commitBody` template:> > I see a commitMessageSuffix config option for vulnerability PRs.
Thanks, I’ll experiment with `commitMessageSuffix` and related settings. Dependabot embeds a YAML block in its commit messages, but as far as I can tell that format is produced by the hosted Dependabot service (not the OSS repo) and isn’t documented. Instead of chasing that, I’ll align on the outputs from the official `dependabot/fetch-metadata` action [1], specifically `updated-dependencies-json`. That way, workflows are interoperable: projects using Dependabot use the official action to retrieve the JSON data, while Solr (with Renovate) can embed the same JSON in the commit message. > Otherwise, renovate can run a custom command for each PR, where we > could hook in more logic. And PRs will be labeled with "security", > so a new solrSecurityBot could run periodically to scan for new > security PRs and do stuff. Great idea, triggering custom automation off the `security` label sounds good. >> 1. Open a JIRA issue to track handling of the vulnerability. > > We could also just keep it simple and handle the vulnerability in > the PR itself. Our project has made it optional to have a JIRA for > everything, and if it does not add some concrete benefit over what the > PR already brings, let's not do it. Agreed: if a PR exists, skipping JIRA is fine. We can always open an issue later if coordination across releases/modules is needed. One question: are we confident Renovate can always open a PR? I have seen Dependabot struggle with purely transitive upgrades (e.g., when a version isn’t present in a version catalog), and in those cases no PR appears. If Renovate has similar constraints, we may want a fallback path (webhooks/labels → workflow) to ensure we still capture and act on those vulnerabilities. >> Because Solr relies on Hadoop’s shaded artifacts, Solr’s security >> depends on Hadoop promptly releasing updates whenever a shaded >> dependency is vulnerable. That’s why I think it’s useful to design >> a workflow compatible with Hadoop’s build tools (Maven/ >> Dependabot), while also aligning with similar efforts in Commons >> and Logging.> > Our hdfs and badoop-auth modules are removed from v10 so I don't > think we need to make design choices based on those specifically. Understood on the v10 removals. My motivation is broader: the less Solr-specific (on-prem Renovate, etc.) the workflow is, the easier it is to maintain and the more reusable it becomes. Thanks, Piotr References: [1] https://github.com/dependabot/fetch-metadata --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
