Re: Improving Dependabot Automation Under New Workflow Requirements

"Piotr P. Karwasz" <[email protected]>
Newsgroups gmane.comp.jakarta.log4j.devel
Message-ID <04b15d38-5265-4041-9850-27ff25cffea2__30529.4344014086$1761911081$gmane$org@mailing.copernik.eu>
Hi all,

On 10.05.2025 22:32, Piotr P. Karwasz wrote:
> As expected, the introduction of required reviews and required checks
> has made our "automatically merge Dependabot PRs" workflow less
> automatic. Currently, for each Dependabot PR:
> 
>   * The commit that adds a changelog entry does not trigger the build
> workflow and therefore fails the required checks. Amending the commit
> manually (which would trigger the workflow) isn't possible through the
> GitHub UI.
>   * A review is required.
>   * We must merge the PR manually once all checks pass.


It’s been nearly six months since we started addressing these issues, so
here’s where things currently stand:

1. There’s a working prototype that allows merging grouped Dependabot
   PRs simply by approving them [1]. I haven’t addressed all the review
   comments yet, as deployment is currently blocked by other issues.
2. Changelog entries in grouped PRs won’t be generated correctly until
   either `dependabot/fetch-metadata#632` is merged or INFRA approves
   using my fork of the action (see [2] and [3]). Alternatively, we
   could move that action to an `apache` repository and maintain it
   collectively.
3. Personal access token (PAT): Having INFRA create a PAT for us [4] is
   no longer necessary. Each of us can add a repository secret
   individually, and I’m happy to handle that.

In the meantime, without waiting for the above to be resolved, I’d like
to take a small but useful step to reduce Dependabot churn:

- Enable a single grouped Dependabot PR per month for all dependencies.
- Disable the old `merge-dependabot-reusable.yaml` workflow. While it
  was a helpful improvement at the time, it’s now causing more trouble
  than benefit (e.g., preventing required checks from running on the
  last commit). Even without branch protection, it often failed on
  `logging-log4j2` due to flaky tests.

What do you think about proceeding this way?

Piotr

[1] https://github.com/apache/logging-parent/pull/419
[2] https://github.com/dependabot/fetch-metadata/pull/632
[3] https://github.com/apache/infrastructure-actions/pull/339
[4] https://issues.apache.org/jira/browse/INFRA-26820
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.