I think Arnout is off for a few weeks but when he gets back, we could look at publishing signed snapshots using CI and provided signing keys. This would be a useful publish event that we could use to see that the process works. Once the snapshots are ok, we can try the process out with our next RC. Around this time, we can make the sbt-pekko-build change to only inline when CI build is used.
On 2024/03/23 09:14:34 Matthew de Detrich wrote: > I have created a PR at > https://github.com/pjfanning/sbt-pekko-build/pull/13 to demonstrate > the disabling of inliner locally if we go ahead with this > > On Sat, Mar 23, 2024 at 9:09 AM Matthew de Detrich > <matthew.dedetr...@aiven.io> wrote: > > > > Now that Pekko is officially out of incubator I think it's a good time > > to explore generating binary artifacts in CI and publishing them to > > Apache's staging repository rather than locally. This has a number of > > advantages > > > > - Massively simplifies release process especially when it comes to > > Pekko modules which have more unique build requirements (i.e. pekko > > core which needs JDK 11 but also points to JDK 8 with JAVA_8_HOME or > > pekko-grpc which uses gradle for the pekko-grpc-gradle plugin) > > - This is especially true of people like myself, who have multiple > > signing keys locally whereby due to the design of sbt-gpg, the process > > of generating artifacts with a non default ASF signing key is quite > > cumbersome > > - Makes releases a lot faster, ideally we would trigger the generation > > + publishing of artifacts into staging just by pushing a git tag > > (which is also the standard way that it's done in most open source > > projects) > > - Can remove the default enablement of Scala 2 inliner in our sbt > > build and only enable it in CI by using sbt's insideCI value (i.e. > > https://github.com/mdedetrich/pekko-streams-circe/blob/main/build.sbt#L144-L155) > > since we no longer have a risk of release managers accidentally not > > enabling it when creating a release artifact > > > > As far as I am aware, we need to get explicit approval from security > > to make this work since they need to verify that we have reproducible > > builds which afaik is now the case (relevant bugs are fixed and > > released in Scala 3.3 aside from one however we found a workaround for > > this). Regarding the signing key, this will be done by the security > > team setting the signing key as a secret in all of our pekko* git > > repos. Thankfully raboof (Arnout Engelen) is part of the Apache > > Security team so he can help navigate through this if there are any > > issues. > > > > In case it's not clear, binary artifacts still need to be manually > > approved i.e. we are not doing a full publish in the CI. We are just > > going to be pushing the artifacts into the staging repository and as > > part of our release guidelines[1] we still need one person to verify > > those binary artifacts before they get promoted to release > > > > 1: > > https://github.com/apache/pekko-site/wiki/Pekko-Release-Process#build-the-release > > > > -- > > Matthew de Detrich > > > > Aiven Deutschland GmbH > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Alexanderufer 3-7, 10117 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > m: +491603708037 > > > > w: aiven.io e: matthew.dedetr...@aiven.io > > > > -- > > Matthew de Detrich > > Aiven Deutschland GmbH > > Immanuelkirchstraße 26, 10405 Berlin > > Alexanderufer 3-7, 10117 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > m: +491603708037 > > w: aiven.io e: matthew.dedetr...@aiven.io > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org
