Update! Here are the changes if interested https://github.com/apache/directory-scimple/compare/4bf269bc609a50b46d7b692c4274494199c1c446...v1.0.0-M2 (there are a couple of regular dependency updates in there too)
Here is the example CI build output for 1.0.0-M2: https://github.com/apache/directory-scimple/actions/runs/13425433400 I started a wiki page collecting this information: https://cwiki.apache.org/confluence/display/directory/Performing+an+Automated+Release There are few notes/findings at the bottom. Before starting this process I would have said with some certainty that the SCIMple build was a Reproducible Build [1], but I found a few minor issue. I'll send out a release vote email soon, but I wanted to give everyone a chance to review the process or ask questions about this automated release build process! [1]: https://reproducible-builds.org/ On Thu, Feb 6, 2025 at 8:17 PM Brian Demers <[email protected]> wrote: > 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] >>> >>>
