Volkan, Please do not wait to release log4j-tools. I am already holding off adding more changelog entries so as to avoid creating more work when the PR is merged. As far as I can tell there is no requirement that log4j-tools MUST be released via CI.
I really would have liked to have all of this done already as this would have been an ideal time to release 2.19.1. Ralph > On Dec 28, 2022, at 6:34 PM, Matt Sicker <m...@musigma.org> wrote: > > 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. >
