We’ve recently completed automated push of Reliza Java Client (SDK) to Maven Central. It’s a Gradle project, so just want to note few things that took more time during this setup.
First, we’re using newer maven-publish plugin. Then note publishing and signing sections in our build.gradle.
Next, our actual build job is here. Note, that it’s an on-demand push that is using technique to use Reliza Hub to route on-demand GitHub Actions builds that I described in my other post.
Finally, biggest issue is how to sign builds in CI. Unfortunately, in-memory signing is poorly documented.
Non-in-memory signing is working as described in Gradle signing plugin documentation – https://docs.gradle.org/current/userguide/signing_plugin.html – so that the gradle.properties looks like:
signing.keyId=24875D73
signing.password=secret
signing.secretKeyRingFile=/Users/me/.gnupg/secring.gpg
Where secring.gpg is exported via the following command:
gpg --keyring secring.gpg --export-secret-keys > ~/.gnupg/secring.gpg
Now, for CI context the recommended way to sign artifacts is in-memory, but unfortunately signing plugin documentation does not provide good way to do that. After a lot of research, the only working solution is presented in this stackoverflow answer: https://stackoverflow.com/questions/57921325/gradle-signarchives-unable-to-read-secret-key/58000485#58000485
Which is essentially this:
gpg --armor --export-secret-keys foobar@example.com \
| awk 'NR == 1 { print "GPG_SIGNING_KEY=" } 1' ORS='\\n' \
> gradle.properties
echo "GPG_SIGNING_PASSWORD=$SIGN_PASS" >> gradle.properties
This creates a workable gradle.properties file that can be used in CI context. And this is the approach we used in the build script.
It would be nice if better documentation is later added to support supplying key via environment variable, but for now I couldn’t find a working solution for that.