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 <elecha...@gmail.com> 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: dev-unsubscr...@directory.apache.org > For additional commands, e-mail: dev-h...@directory.apache.org > >
