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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org