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
