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.