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]
