CI: Gradle dependency verification update workflow

[nzb-tuxxx]

Draft implementation for #2006.

This adds a scheduled/manual GitHub Actions workflow to maintain Gradle dependency verification metadata for Sparrow. The goal is to make dependency artifact changes explicit and reviewable, including platform-specific artifacts resolved during packaging.

This is intended as a defense-in-depth improvement. It does not solve artifact provenance by itself, but it makes Maven artifact changes visible in the source tree and reviewable through the normal PR workflow.

Workflow

The workflow uses the same runner set as the release packaging workflow:

• ubuntu-22.04
• ubuntu-22.04-arm
• windows-2022
• macos-15-intel
• macos-14

It runs the platforms serially so Gradle can update the same verification metadata incrementally without a custom XML merge step.

Steps:

• Bootstrap gradle/verification-metadata.xml if it does not exist yet.
• Run Gradle dependency verification metadata generation in two passes:
  • first sha512
  • then pgp,sha512
• Export the armored verification keyring with --export-keys.
• Pass the generated verification-metadata.xml and verification-keyring.keys to the next platform job.
• After the final platform job, compare the generated files with the repository state.
• If changes are detected, push/update a fixed automation branch.
• Open a PR only if no PR for that branch already exists.
• If the existing automation branch already contains the generated changes, do not create a new commit.

Permissions

Most jobs run with read-only repository permissions:

permissions:
  contents: read

Only the final PR update job requests write permissions:

permissions:
  contents: write
  pull-requests: write

The write permission is needed because that job pushes/updates the fixed automation branch and opens or updates the PR.

Please review whether this permission model is acceptable for Sparrow, or whether you would prefer a different approach, such as a read-only workflow that only uploads generated files as artifacts, or an external fork/bot workflow that opens PRs from outside the main repository.

Configuration

The workflow has conservative defaults:

env:
  ALLOW_ADDITIONAL_ARTIFACT_CHECKSUMS: 'false'
  CLEAN_STALE_VERIFICATION_METADATA: 'false'
  CACHE_GRADLE_WRAPPER_DISTRIBUTION: 'true'

ALLOW_ADDITIONAL_ARTIFACT_CHECKSUMS

• Default: false
• Controls how Gradle also-trust checksum additions are handled.
• false means the workflow aborts if Gradle adds an additional trusted checksum for an already-known artifact coordinate.
• This is conservative because an additional checksum for the same artifact coordinate may indicate that the repository served different artifact content.
• Set to true only if such additions should be allowed into the automated update PR.

CLEAN_STALE_VERIFICATION_METADATA

• Default: false
• Controls whether the first platform job starts from the committed verification files or from a clean bootstrap file.
• false keeps normal incremental Gradle behavior.
• true intentionally regenerates verification metadata from a clean starting point across all release platforms, so stale metadata entries can be removed.
• This is off by default because cleanup PRs may remove old entries and should be reviewed more carefully.

CACHE_GRADLE_WRAPPER_DISTRIBUTION

• Default: true
• Controls whether the workflow caches the Gradle wrapper distribution directory.
• true caches only ~/.gradle/wrapper/dists, so repeated runs can avoid downloading the Gradle distribution again.
• This was added after a scheduled workflow run failed while downloading Gradle with Server returned HTTP response code: 504 for URL.
• The cache does not include Gradle dependency artifacts, Maven artifacts, or keyring state.
• Set to false if the wrapper distribution cache should be disabled for debugging or fork test runs.

Why a separate composite action

The repeated Gradle/update/upload logic is kept in a local composite action:

• keeps the workflow readable
• avoids duplicating the same Gradle commands across five platform jobs
• keeps the serial platform chain explicit in the workflow
• avoids introducing an external PR-creation action or custom XML merge script
• makes the reusable update step easier to review independently

Tested

This has been tested in a fork with:

• bootstrapping from no committed gradle/verification-metadata.xml / gradle/verification-keyring.keys
  • the workflow generated both files
  • the workflow opened an update PR
• missing metadata repair
  • one Linux JavaFX artifact entry was intentionally removed
  • one macOS JavaFX artifact entry was intentionally removed
  • the workflow regenerated the missing entries and opened/updated the PR
• existing automation branch handling
  • repeated runs update the same fixed automation branch
  • no duplicate PR is opened for the same dependency metadata update
• no-op automation branch handling
  • if the existing automation branch already contains the generated metadata changes, the workflow exits without creating another equivalent commit
• additional checksum handling
  • changing an existing artifact checksum makes Gradle generate also-trust
  • with the conservative default, the workflow aborts instead of opening an automated PR for that case

I have enabled this workflow in my fork and would suggest collecting some experience there first, including waiting for real artifact updates to confirm they are reflected correctly in generated PRs, before considering this for merge; early feedback is of course very welcome.