This sounds amazing! Thanks for championing this effort! For signing, there’s some project out there that lets you use OIDC for signing things and keeping a sort of certificate transparency log so that you can verify that not only was an artifact signed by a valid signature, but it’s also done by the expected key for a particular release. See https://www.sigstore.dev/ for details. I’m not sure if it works with GPG keys or Maven or anything, but it could be a useful basis for further release automation in the future (even if it’s something more custom to the ASF). — Matt Sicker
> On Dec 28, 2022, at 14:42, Volkan Yazıcı <vol...@yazi.ci> wrote: > > Hello, > > I want to share some updates from my side on what I have been working on > for the last couple of months. In particular, I expect certain changes to > have an ASF-wide impact! Sounds interesting? Continue reading. > > *What is up with `maven-changes-plugin`?* > > The current `site` phase takes ages to complete. This significantly hinders > releases and more frequent website updates. The main culprit is `site` > phase plugins need to be executed for 50+ modules. As my investigation > turned out, we can actually either drop or replace all such plugins, except > one: `maven-changes-plugin`, that is used to generate the changelog from > `changes.xml`. `maven-changes-plugin` is also a major source of > merge-conflicts in between feature branches and PRs, since they all need to > touch to the same file: `changes.xml`. > > *Is it only about overhauling the `site` phase?* > > No. As we agreed on, we want to migrate the issue tracking from JIRA to > GitHub Issues. `maven-changes-plugin` blocks us there too, since it only > supports a single issue tracking system. > > *Enter `log4j-changelog`* > > I have written simple Java command line applications to perform the > following tasks: > > 1. Populate > `src/site/changelog/<releaseVersion>/<issueId>_<description>.xml` files > from `changes.xml` > 2. Generate AsciiDoc-formatted changelog files from the populated > `src/site/changelog` > 3. Make `src/site/changelog` ready before a release > > These technical tools will not only help us to replace > `maven-changes-plugin`, support multiple issue trackers, and enable great > simplification of the `site` phase, due to its one-changelog-file-per-issue > convention, they will make changelog merge conflicts a thing of the past > too! > > Okay, great! Since the `maven-changes-plugin` successor is there, what are > we exactly waiting for? > > *Enter `log4j-tools`* > > I have implemented `log4j-changelog` as a not-deployed Log4j module, though > Ralph insisted on not having this within Log4j to make it available for > other Log4j projects and since it needs to be shared by (and hence, sync'ed > in between) `release-2.x` and `master` branches. He proposed that we host > this in `log4j-tools` <https://github.com/apache/logging-log4j-tools>. > Since `log4j-tools` repository never had a release before, I let my > imagination go wild there: > > - Adopted the Maven-recommended way of setting up a BOM: > `logging-parent` parents `log4j-bom`, which parents `log4j-parent`, which > parents all other modules. There the effective POM of `log4j-bom` is > stripped-down from its parent and all unnecessary weight via > `flatten-maven-plugin` voodoo. > - Switched to CI-friendly Maven versioning > <https://maven.apache.org/maven-ci-friendly.html> > - Configured GitHub Actions to make releases! > > (As you might guess, if experiment succeeds, I will port all these fancy > stuff to Log4j too.) > > *Releasing... via GitHub Actions!?!* > > ASF project artifacts are required to be signed and up until now that has > **always** been performed manually by release maintainers. Releasing **and > signing** artifacts in a fully-automated fashion in CI... "Surely You're > Joking, Mr. Feynman!" But I am not! I have shared a technical > implementation proposal in `members@`, got approval from ASF Security Team > head Mark J. Cox > <https://lists.apache.org/thread/t1fbn11m70sy9df86xgzzp0fllg38p9q>, and now > I am waiting for INFRA-23996 > <https://issues.apache.org/jira/browse/INFRA-23996> to be implemented! > > What does this effectively mean? To the best of my knowledge, *`log4j-tools` > will be the first ASF project ever that is released via CI!* This will > enable various release automation enhancements, not to mention the software > supply chain traceability it will bring as well. > > *Where are we now?* > > Once INFRA-23996 <https://issues.apache.org/jira/browse/INFRA-23996> is > implemented and `log4j-tools` (containing `log4j-changelog`) is released, > the following PR train will be merged: > > - #1145 <https://github.com/apache/logging-log4j2/pull/1145> – replace > `maven-changes-plugin` with `log4j-changelog` > - #1166 <https://github.com/apache/logging-log4j2/pull/1166> – simplify > `site` goal (`./mvnw site` takes ~30 seconds!) > - #1172 <https://github.com/apache/logging-log4j2/pull/1172> – update > sources, docs, links, etc. to reflect the migration from JIRA to GitHub > Issues > > *What are we waiting for?* > > We *_can_* release `log4j-tools` without INFRA-23996 > <https://issues.apache.org/jira/browse/INFRA-23996>, the old school way, > i.e., via running `./mvnw deploy` from a personal laptop. That said, I > believe releasing `log4j-tools` via CI will have a way bigger impact beyond > the scope of Log4j, and `log4j-tools` constitutes a great candidate for > such an experiment. We are all set: `log4j-tools` GitHub Actions workflows > <https://github.com/apache/logging-log4j-tools/blob/master/.github/workflows/build.yml> > are ready to make an automated release. Infra team has indicated in > INFRA-23996 <https://issues.apache.org/jira/browse/INFRA-23996> that they > will implement it in a couple of days. Given how close we are to an > automated release, I will wait for my grand infra revamp scheme to unfold.
