Roadmap for Apache Logging workflows

[ppkarwasz]

Our current v12 generation of reusable workflows works great, but new challenges like supply-chain security arise, which will require some modifications and hardenings.

These are my thoughts for version 13 of logging-parent.

Current reusable workflows

The gha/v0 branch currently offers these reusable workflows:

Workflow	Purpose	Planned changes
analyze-dependabot-reusable.yaml	Extracts Dependabot PR metadata for further processing	none
build-reusable.yaml	Main CI build on a 3-OS matrix, with optional site build and reproducibility check	reproducibility option, caching, site generation
codeql-analysis-reusable.yaml	CodeQL analysis of the consumer repositories	caching
deploy-release-reusable.yaml	Releases: version and changelog commits, Nexus staging, distributions, SVN upload	commit signing, supply chain, distributions
deploy-site-reusable.yaml	Builds the website and deploys it to a Git branch	site generation, commit signing
deploy-snapshot-reusable.yaml	Deploys snapshot artifacts to Nexus	caching
process-dependabot-reusable.yaml	Adds changelog entries to Dependabot PRs and auto-merges them	none
verify-reproducibility-reusable.yaml	Verifies build reproducibility against a reference repository	caching

Deprecated reproducibility-check-enabled in CI workflow

Affected workflows: build-reusable.yaml

Our build-reusable workflow has a reproducibility-check-enabled option that runs a reproducibility check inside the CI build. The check has since been moved to the separate verify-reproducibility-reusable workflow, but the option has been kept for backward compatibility and still defaults to true. We should remove it.

Cache optimization in CI workflow

Affected workflows: all workflows using setup-java with cache: maven (build-reusable.yaml, codeql-analysis-reusable.yaml, deploy-release-reusable.yaml, deploy-site-reusable.yaml, deploy-snapshot-reusable.yaml) and verify-reproducibility-reusable.yaml

Maven Central artifacts are platform-independent and immutable, so we could use a single cache for all platforms. However, the local Maven repository ~/.m2/repository has two problems:

• It is not under the $GITHUB_WORKSPACE tree, so it must be referenced by an absolute path. The actions/cache action uses the path of the cached files as hidden key, which prevents reuse between platforms.
• It is used as both a Maven Central cache and staging area for local artifacts, so every mvn install makes it non-reusable.

The second problem already forced verify-reproducibility-reusable to avoid the setup-java cache and manage its own monthly-keyed cache, to prevent artifacts built by other workflows from skewing its results.

We could replace caching the local Maven repository with Mimír (see PR #389), so we have more space available for other caches.

Deploy site simplification

Affected workflows: build-reusable.yaml, deploy-site-reusable.yaml, new build-site-reusable.yaml

Currently, the deploy-site-reusable.yaml workflow performs two tasks, once a change is pushed to a website branch:

1. Generates the website,
2. Deploys the website to another branch.

The first task is also performed by build-reusable.yaml (site-enabled option) to gate PRs, so we could refactor the workflows to avoid repeating the same tasks:

• Remove site generation from build-reusable.yaml: this way we'll lose a gate that checks PRs from the documentation side.
• Create a new build-site-reusable.yaml that performs only the site generation part of the build. Ideally this should reduce to:

  mvn compile -P <profile_that_skips_code_only_checks>
  mvn site

  plus an upload of the website to the GitHub workflow run.
• This way deploy-site-reusable.yaml could be reduced to checking out the right branch and downloading the artifact. Currently it contains a lot of complexity due to two checkouts in the same directory.

Commit signing

Affected workflows: deploy-site-reusable.yaml, deploy-release-reusable.yaml

Today deploy-site-reusable uses the release GPG key only to (optionally) sign the website commits, while deploy-release-reusable uses it to sign the release commits, the Maven artifacts (via sign-maven-plugin) and the distributions.

Commit signing is not very useful and requires one of our most important secrets: the release GPG key. That key should not be available to most workflows, i.e. it must be an "Environment secret", not an "Action secret".

We should use it only to sign release artifacts for backward compatibility. A SLSA Provenance attestation should also be produced by the workflow that built the artifacts.

Supply chain of release branches

Affected workflows: deploy-release-reusable.yaml (and a new profile in logging-parent)

Since May 2025 we have reviewed all the commits on our 2.x and main branches, which allows us to declare a SLSA Source Level 4 for those two branches. Unfortunately the release commits are not on those branches, so we can not prove that we reviewed all the commits from one release to the next one. The missing link is the release/* branches, which should ideally be protected too.

Currently deploy-release-reusable makes three commits on those branches (set the revision, update the project.build.outputTimestamp, release the changelog), but we could:

• either move that helper workflow to make changes to PRs to release/* (change the <revision> of the artifact to the version number of the target branch and update timestamp),
• or add a profile to logging-parent that does those changes. Pretty much the equivalent of spotless:apply, but for releases:
  1. It changes the artifact revision to the one given as parameter,
  2. It updates the timestamp,
  3. It releases the changelog.

On the release-reusable side, the workflow would only check that:

1. The value of revision is the same as the version number of the branch,
2. The timestamp is not too much in the past,
3. No unreleased changelog entries exist.

I think this is the only workflow that should have access to our GPG key and it should be gated by a release environment, which would require two committers to unlock.

Source and binary distributions

Affected workflows: deploy-release-reusable.yaml (and the distribution profile in logging-parent)

I really don't like the fact that the binary and source releases are generated by a minimalistic Groovy script, which doesn't even support UNIX permissions. We could of course improve this and make it a Maven plugin, but I think there is a simpler solution:

1. In 2026 nobody needs a binary distribution, we should just drop it and replace it with a script that downloads artifacts from Maven Central and verifies them with our GPG key.
2. The source archive can be generated by git archive, which has the advantage of working without any Java, .NET or C++ environment, so it could be reused by all the projects. It runs in the workflow's local clone, so it does not depend on GitHub's server-side support, and its --add-file option leaves room for injecting files that are not Git-tracked, like the frozen NPM dependency manifests planned as a follow-up of PR #506.