Quick update: Request for GPG key (and nexus config) to INFRA: https://issues.apache.org/jira/browse/INFRA-26517
The details are in the issue, but to save you a click: - I created a GitHub Action that checks for build reproducibility (it can on demand against any git ref): https://github.com/apache/directory-scimple/blob/develop/.github/workflows/build-reproducible.yml - The previous SCIMple release did not generate SBOMs, but the next release will: https://github.com/apache/directory-scimple/blob/49fc815/pom.xml#L923-L935 Out of scope for now are the post-vote tasks (e.g. updating the site), that's a different topic (updating the version <https://github.com/apache/directory-site/blob/8886763/config.toml#L35-L44> should be _easy_, but generating the new/announcement is a little more work, we can start a different thread if/when we do that) Left to do: - Once INFRA sets up everything, I'm going to mostly copy what the Apache Logging folks are doing here: https://github.com/apache/logging-parent/blob/main/.github/workflows/deploy-release-reusable.yaml - Create a quick wiki page on the process - Vote on the release! On Wed, Feb 5, 2025 at 9:00 PM Brian Demers <[email protected]> wrote: > Sorry, I realized my last message didn't go to the list, only Emmanuel > (and a minor update below as well) > > I'd like to get this applied to all the Directory projects though, and >> IMO this is the thing to be discussed, beside the technical details. > > > +1 > > Once I make the Infra request, it _should_ be possible for all Directory > projects to implement assuming each repo meets the Infra policies. > > As I go through the process I can take notes of both the requirements and > how to implement them. > > There are some details that are not clear to me yet, like infra will > create a GPG key and add as a CI secret, I assumed this was one per project > (shared between each module), but maybe that is (or should be) one for each > CI system (GH Actions, Jenkins, etc). > Should there be an explicit check for reproducibility in the release > process (e.g. `mvn artifact:compare`) [1] > Should CI dependency cache be disabled for these builds. > (my assumption is "yes" for both, but I'd like to understand the > requirements and the best practices) > > [1] > https://maven.apache.org/plugins/maven-artifact-plugin/usage.html#checking-reproducible-build-comparing-current-build-against-prev > > I just asked about docs and processes on the monthly ASF Infra roundtable > call. > The ASF is working on tooling to help automate the whole release process > (build and vote, etc). But we can get started with the build side of > things now. > A few Infra folks stressed the need for reproducible builds as a > requirement (in the future an attestation to verify it). > There was also a recommendation to create SBOMs as well. > > Reproducible builds get trickier once we start thinking about application > builds (especially cross platform), but for a _typical_ Java library we can > assume reproducible means artifacts created should be byte-for-byte the > same between two builds. > > TL;DR, I'll get the ball rolling, and create a GH Action that will: > - Deploy to a staging repo > - Run the build again with `artifact:compare` > > We can then follow up with improvements, and then figure out how we should > move forward with other Directory repos. > > > > > > On Tue, Feb 4, 2025 at 3:33 AM Emmanuel Lecharny <[email protected]> > wrote: > >> Hi Brian, >> >> I'm sure in favor of such automatisation./ Cutting a release is already >> such a pain that any system that make it simpler is very welcome. >> >> I'd like to get this applied to all the Directory projects though, and >> IMO this is the thing to be discussed, beside the technical details. >> >> Le 04/02/2025 à 04:04, Brian Demers a écrit : >> > We've had a couple of community contributions to SCIMple, so I'd like to >> > get a release out. >> > >> > Leading up to this release, I'd like to set up automated releases for >> > SCIMple (possibly as a canary for other Directory projects, but that's >> TBD) >> > >> > *NOTE*: This does NOT replace the vote requirements! >> > >> > You can read the details here: >> > https://infra.apache.org/release-signing.html#automated-release-signing >> > >> > Personally, I see few big benefits: >> > - Remove toil >> > - Release from trusted hardware >> > - Requires builds to be reproducible >> > >> > *How this could work in practice:* >> > 1. Release manager pushes a tag to git >> > 2. CI (GitHub Actions) runs build and publishes artifacts to a Nexus >> > Staging repo (replacing the need for the release manager to do it) >> > 3. Release manager sends out a vote email >> > ... Release process continues as normal >> > >> > *What is next:* >> > - I don't think this needs a vote, but I'd like to get a general >> consensus. >> > - Creation of a INFRA JIRA ticket to do the following: >> > - ASF Infra sets up a signing key and adds it to our KEYS file ( >> > https://dist.apache.org/repos/dist/release/directory/KEYS ?) >> > - ASF Infra sets up secrets (not available to forks, etc) >> > - I tweak the SCIMple build to watch for tags (probably something like >> tags >> > matching `v\d.*` to avoid confusion any manual processes) >> > - I cut a SCIMple release (1.0.0-M2) using the new process >> > - If it works, great... if not I fall back to running it manually >> > - Vote >> > >> > Thoughts? >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
