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

Reply via email to