I would not be opposed to make the choice of signing key a required argument for the relevant release script(s).
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
