Group Dependabot PRs and remove merge-dependabot

[ppkarwasz]

This change adds grouping to all dependabot configurations to limit the number of open PRs to one.

It also removes the merge-dependabot workflow, which is no longer useful in case of grouped upgrades.

[vy]

This effectively means dependency updates will not contain a changelog entry anymore. I'm reluctant to accept this.

I thought we agreed to "disable dependabot" (i.e., delete dependabot.yaml) and restore it once the CI workflow is fixed. Have I misunderstood you?

[ppkarwasz]

I prefer to keep Dependabot alive as a reminder. Having a partial Dependabot PR is better than having no PR at all.

Until we solve the blocker for Dependabot automation, we can always complete those PRs ourselves or I can share a short Python script to generate the entries.

[vy]

I prefer to keep Dependabot alive as a reminder. Having a partial Dependabot PR is better than having no PR at all.

I'm not very keen on this idea, since it will take a single click for a maintainer to approve such a PR, and effectively lose the trail of updates, which are necessary to generate changelog entry files.

Until we solve the blocker for Dependabot automation, we can always complete those PRs ourselves or I can share a short Python script to generate the entries.

Can you put that in a Groovy script that gets executed in a dedicated logging-parent profile, that is, ./mvnw -P generate-dependabot-changelog apache/logging-log4j2 12345?

[vy]

I will implement the logging-parent script myself – you can proceed.

[ppkarwasz]

Can you put that in a Groovy script that gets executed in a dedicated logging-parent profile, that is, ./mvnw -P generate-dependabot-changelog apache/logging-log4j2 12345?

I’m concerned that, for security reasons, we cannot rely on a Groovy script to generate the changelog entries.

Regardless of whether we split the workflow into two steps (which would indeed make it easier to review), changelog generation effectively consists of two distinct phases:

1. Reading Dependabot changes (unprivileged)
   This step can safely use a Groovy script, relying on mvnw, Maven and the Maven Groovy Plugin, provided it runs as pull_request.

2. Writing changelog entries to the repository (privileged)
   Once the PR commit is checked out, we must be careful not to execute any script or dependency defined in the repository itself. Concretely:

   • We should not run ./mvnw to determine the major version; that value can and should be passed explicitly as an argument.
   • More importantly, we must not run ./mvnw to execute a Groovy script whose dependencies or versions could have been modified in the PR.

For this reason, using a Groovy script in the privileged part of the workflow is not something I would be comfortable with.