+1 to automating release signing. As it stands now, this step requires a PMC member to add a new release manager's GPG key which can add time to getting a release started. This also results in the public key used to sign each release changing from one version to the next, as different release managers have different keys. Making releases easier to perform and providing a standard signing key for each release both seem like wins here.
On Wed, May 3, 2023 at 2:40 PM Danny McCormick via dev <dev@beam.apache.org> wrote: > Hey everyone, I'm currently working on improving our release process so > that it's easier and faster for us to release. As part of this work, I'd > like to propose automating our release signing step (the push java > artifacts step of build_release_candidate.sh > <https://beam.apache.org/contribute/release-guide/#run-build_release_candidatesh-to-create-a-release-candidate>) > using GitHub Actions. > > To do this, we can follow the guide here > <https://infra.apache.org/release-signing.html#automated-release-signing> and > ask the Infra team to add a signing key that we can use to run the > workflow. Basically, the asks would be: > > 1) Add a signing key (and passphrase) as GH Actions Secrets so that we can > sign the artifacts. > 2) Allowlist a GitHub Action (crazy-max/ghaction-import-gpg) to use the > key to sign artifacts. > 3) Add an Apache token (name and password) as GH Actions Secrets so that > we can upload the signed artifacts to Nexus. > > Please let me know if you have any questions or concerns. If nobody > objects or raises more discussion points, I will assume lazy consensus > <https://community.apache.org/committers/lazyConsensus.html> after 72 > hours. > > Thanks, > Danny >
