feat: add process-dependabot-reusable workflow (Bash-based alternative)

[ppkarwasz]

This PR introduces a reusable GitHub Actions workflow, process-dependabot-reusable, designed to streamline the handling of Dependabot pull requests across repositories — implemented entirely with shell scripts.

This serves as a Bash-based alternative to #418, which uses TypeScript.

🔄 Key Differences from #418

• Trigger: Runs on pull_request_target (not push), which is required by the dependabot/fetch-metadata action.

• Implementation: Written using standard POSIX tools with a few dependencies:

  • bash – some Bash-specific constructs are used
  • jq – for processing JSON output from dependabot/fetch-metadata
  • xmlstarlet – for parsing pom.xml and generating a changelog XML file
  • git – to commit and push any changes
  • gh – to enable "auto-merge" on the pull request

This approach avoids the Node.js/TypeScript toolchain and relies only on standard CLI tools commonly available in CI environments.

Updated version

The updated version of this PR splits the workflow into two parts:

• Unprivileged workflow (analyze-dependabot-reusable):
  Runs on pull_request with no permissions. It analyzes Dependabot PRs and generates metadata safely.

• Privileged workflow (process-dependabot-reusable):
  Uses the metadata from the unprivileged step to generate changelog files and enable the "auto-merge" option. Requires access to our GPG key and Personal Access Token.

[ppkarwasz]

After running some tests, I identified the following limitations with this workflow stemming from the use of dependabot/fetch-metadata:

• As previously mentioned, the workflow must run with the pull_request_target event (see fetch-metadata can not fetch metadata when using workflow_run event dependabot/fetch-metadata#490). This imposes a restriction: the token with write permissions to the repository cannot be stored in Dependabot Secrets, and instead must be stored in Actions Secrets. The downside is that Actions Secrets are accessible to a broader range of workflows, not just those triggered by dependabot[bot].

• Until Support newVersion and prevVersion for updates with multiple dependencies dependabot/fetch-metadata#402 is resolved, version metadata will not be available for grouped PRs, which is a blocker: the changelog entries will not have any information about the version to which the dependency was upgraded.

  🔧 Update: this will be fixed by feat: Parse versions from metadata links dependabot/fetch-metadata#632

[Copilot]

Pull Request Overview

This PR adds a new Bash-based reusable GitHub Actions workflow for processing Dependabot pull requests and a complementary workflow for analyzing them.

• Introduces the process-dependabot-reusable workflow that generates changelog entries and enables auto-merge.
• Splits the workflow into two parts (analyze and process) and updates related documentation and examples.
• Adds an XML changelog entry and updates workflow examples to reflect the new structure.

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/site/antora/modules/ROOT/pages/workflows.adoc	Updates documentation to include examples and explanations for the new workflows.
src/site/antora/modules/ROOT/examples/process-dependabot.yaml	Provides an example usage of the new process workflow.
src/site/antora/modules/ROOT/examples/analyze-dependabot.yaml	Provides an example usage of the new analyze workflow.
src/changelog/.12.x.x/add-deploy-profile.xml	Adds a changelog entry documenting the addition of the new workflow.
.github/workflows/process-dependabot-reusable.yaml	Implements the workflow that generates changelog entries and enables auto-merge for Dependabot PRs.
.github/workflows/analyze-dependabot-reusable.yaml	Implements the workflow to analyze Dependabot PRs and prepare metadata for processing.

Comments suppressed due to low confidence (2)

.github/workflows/process-dependabot-reusable.yaml:168

• Consider using the PR_URL extracted earlier from the fetched metadata (set in GITHUB_ENV) instead of relying on github.event.pull_request.html_url to ensure consistency across the workflow.

          PR_URL: ${{ github.event.pull_request.html_url }}

.github/workflows/process-dependabot-reusable.yaml:104

• [nitpick] The indentation of the 'exit 1' statement (line 106) is inconsistent with the block structure; aligning it with the preceding echo statement will improve readability.

          if [[ ! $revision =~ ^[0-9]+\.[0-9]+\.[0-9]+(-SNAPSHOT)?$ ]]; then

[vy]

Can you keep this PR on hold, please? I will suggest an alternative in a day or two.

[ppkarwasz]

Sure, happy to wait a bit, though I'll note this PR has been open since June last year, mostly blocked on the dependabot/fetch-metadata side. Now that a new release finally landed on March 26th, I took the opportunity to bring it back in shape and strip it down to the bare essentials: no GPG signing, no unnecessary inputs or dependencies. I think it's about as simple as it gets at this point.

PR ppkarwasz/logging-log4j2#606 tests this in practice if you want to see how it behaves end-to-end.

I'm genuinely happy to look at alternative proposals, but one heads-up: please don't suggest collapsing this into a single pull_request_target workflow just to save a step or two. Even setting aside whether it'd be safe in this specific case, pull_request_target is a hard no under the ASF GitHub Actions policy: https://infra.apache.org/github-actions-policy.html

Getting an exception through INFRA would create way more churn than the two-workflow split is worth. If the policy ever tightens up around workflow_run too (as it should), we can revisit, but for now, the split is both policy-compliant and the right call.

[vy]

A Personal Access Token (PAT) with contents:write permission must be provided instead.

@ppkarwasz, would you mind explaining how do we do that, please? Do we create an INFRA ticket?

I'm genuinely happy to look at alternative proposals

I suggest adding a Groovy script to gha/v0 that maintainers can run using a Maven profile inherited from logging-parent and pass it a Dependabot PR URL. For instance:

./mvnw -P generate-dependabot-changelog https://github.com/apache/logging-parent/pull/X

This will

1. Checkout to the associated PR branch
2. Generate changelog entries

Consequently, the maintainer can review these changes, commit, and push them. Since the commits will be originating from a maintainer, the CI will run without any extra permissions, PAT tokens, etc.

[ppkarwasz]

A Personal Access Token (PAT) with contents:write permission must be provided instead.

@ppkarwasz, would you mind explaining how do we do that, please? Do we create an INFRA ticket?

We can upload a secret via gh secret create. To test it, you can run:

gh secret list

on the main Log4j repository. There should be a TEST_SECRET I uploaded 7 months ago.

[ppkarwasz]

I suggest adding a Groovy script to gha/v0 that maintainers can run using a Maven profile inherited from logging-parent and pass it a Dependabot PR URL. For instance:

./mvnw -P generate-dependabot-changelog https://github.com/apache/logging-parent/pull/X

On one side, I would like to generate changelogs manually, but on the other hand I don't want to do it, if the CI can.

I wouldn't be too much concerned about using a PAT: we use reusable workflows after all and all secrets must be passed by the caller explicitly. The only workflow with access to the PAT will be process-dependabot-reusable.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 11 comments.

Comments suppressed due to low confidence (1)

src/site/antora/modules/ROOT/examples/analyze-dependabot.yaml:24

• The example sets permissions: { }, which results in a permissionless GITHUB_TOKEN. If the reusable analyze-dependabot workflow needs to call the GitHub API (via dependabot/fetch-metadata), the caller should grant minimal read permissions (e.g., pull-requests: read and contents: read).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ppkarwasz]

I haven't tested yet, but apparently converting a PR to draft and back triggers workflows.

@vy, do you have anything against this PR if we don't use a PAT, but tricks?

[vy]

@vy, do you have anything against this PR if we don't use a PAT, but tricks?

@ppkarwasz, if we don't use a PAT, how will it work?

[ppkarwasz]

You can for example:

• Convert the PR to draft and back, or
• Update the PR to the latest branch.