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
