[D] Roadmap for Apache Logging workflows [logging-log4j2]

GitHub user ppkarwasz created a discussion: Roadmap for Apache Logging workflows

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](#deprecated-reproducibility-check-enabled-in-ci-workflow), [caching](#cache-optimization-in-ci-workflow), [site generation](#deploy-site-simplification) |
| `codeql-analysis-reusable.yaml`        | CodeQL analysis of the consumer repositories                                       | [caching](#cache-optimization-in-ci-workflow)                                                                                                                                     |
| `deploy-release-reusable.yaml`         | Releases: version and changelog commits, Nexus staging, distributions, SVN upload  | [commit signing](#commit-signing), [supply chain](#supply-chain-of-release-branches), [distributions](#source-and-binary-distributions)                                           |
| `deploy-site-reusable.yaml`            | Builds the website and deploys it to a Git branch                                  | [site generation](#deploy-site-simplification), [commit signing](#commit-signing)                                                                                                 |
| `deploy-snapshot-reusable.yaml`        | Deploys snapshot artifacts to Nexus                                                | [caching](#cache-optimization-in-ci-workflow)                                                                                                                                     |
| `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](#cache-optimization-in-ci-workflow)                                                                                                                                     |

## 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](https://github.com/apache/logging-parent/pull/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:
  ```bash
  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](https://github.com/apache/logging-parent/pull/506).

GitHub link: https://github.com/apache/logging-log4j2/discussions/4221

----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]