Your observations about the release process are correct. (B) sounds like a better option to me because it will prevent creation of one more global setting. However both solutions are workable.
On Wed, Mar 6, 2019 at 8:08 AM Robert Bradshaw <[email protected]> wrote: > I would not be opposed to make the choice of signing key a required > argument for the relevant release script(s). > I agree with this. My question would be, how do we ensure that same key is passed to different scripts. Today release consists of using multiple scripts, it would be a simple mistake for the release manager to use a different key for different scripts. > > On Wed, Mar 6, 2019 at 3:44 PM Michael Luckey <[email protected]> wrote: > > > > Hi, > > > > After upgrade to gradle 5 @altay (volunteering/selected as release > manager) was hit by an issue [1] which prevented signing of artefacts. He > was unfortunately forced to rollback to gradle 4 to do the release. > > > > After fixing a configuration issue within beam it seemingly revealed an > underlying regression in gradle's signing plugin itself [2]. > > > > If I understand correctly, beams current setup works along the following > line: On initial configuration any release manager will setup the to be > used key for git only [3], but we never did something similar on gradles > behalf. Which results in the signing plugin (delegating to gpg cmd line) > using whatever gpg considers to be the default key, whether explicitly > configured with gpg.conf or implicitly. > > > > 1. Am I right in assuming that these keys not necessarily have to match? > I.e. that the key used for signing the release tag ('git tag -s') is not > necessarily the key used for signing the artifacts? > > 2. Am I right to assume, that we want/require them to be the same? I.e. > the key which is uploaded to Beam KEYS file? > > > > Now after grade 5 stopped defaulting to gpg's default key, we somehow > need to explicitly specify the key to use for the signing plugin. The > simplest solution would be to just add a note to the release guide how to > solve that issue on dev side. Which likely will lead to some frustration as > it is easy to miss. > > > > So I would like to integrate something into the used scripting. > > > > Options: > > > > A: During one time setup, developer is forced to select the proper key. > This key will be set to (global) git configuration [4]. We could add this > key also to gradle.gradleHome gradle.properties file as > 'signing.gnupg.keyName' which then would be used by gradles signing plugin. > > > > Obvious drawback here would be that this is a global configuration (ok, > the same problem we have already for git), which might not be appropriate > for all devs. > > > > B: Read the 'git config user.signingkey' on script execution and pass > this as '-Psigning.gnupg.keyName' parameter to the gradle run. Of course > this will only work, iff the git config is set. So would it be save to > assume such? > > > > Drawback here, of course, is someone not using the release script > missing to set the signing key. > > > > Of course, both will not solve any issue with source.zip releases and > pythons signing key, which, as far as I can tell also rely on gpgs default > key which might conflict with 1. above? > > > > Any thoughts about this? > > > > michel > > > > > > > > > > [1] https://issues.apache.org/jira/browse/BEAM-6726 > > [2] https://github.com/gradle/gradle/issues/8657 > > [3] > https://github.com/apache/beam/blob/master/website/src/contribute/release-guide.md > > [4] > https://github.com/apache/beam/blob/master/release/src/main/scripts/preparation_before_release.sh#L44-L48 >
