How to Sign and Release to The Central Repository with GitHub Actions

how_to_sign_and_release_to_the_central_repository_with_github_actions.md

How to Sign and Release to The Central Repository with GitHub Actions

GitHub allows automated builds using GitHub Actions. A commonly asked question is how to release artifacts (packaged Java jars) built by Maven and Gradle to The Central Repository. The GitHub Actions documentation provides only part of the answer.

So, first, configure your Maven project for staging artifacts to The Central Repository, by reading through Configuring Your Project for Deployment and following those steps. Please make sure that the maven-gpg-plugin is configured to prevent gpg from using PIN entry programs, as follows:

<configuration>
  <gpgArguments>
      <arg>--pinentry-mode</arg>
      <arg>loopback</arg>
  </gpgArguments>
</configuration>

At this point, you should be able to manually stage your artifacts to The Central Repository.

Next, set up a basic GitHub Actions workflow to build your project. Take a look at Publishing Java packages with Maven, and complete all the steps there.

At this point, you will find that you are missing one step - being able to sign your Maven-built jar files within your GitHub Actions workflow. You can follow the steps below to sign artifacts in GitHub actions. The trick involves loading in your private key into GitHub Actions using the gpg command-line commands.

1. Export your gpg private key from the system on which you have created it.
   1. Find your key-id (using gpg --list-secret-keys --keyid-format=long)
   2. Export the gpg secret key to an ASCII file using gpg --export-secret-keys -a <key-id> > secret.txt
   3. Edit secret.txt using a plain text editor, and replace all newlines with a literal "\n" (backslash + n) until everything is on a single line
2. Set up GitHub Actions secrets
   1. Create a secret called OSSRH_GPG_SECRET_KEY using the text from your edited secret.txt file (the whole text should be in a single line) as the value
   2. Create a secret called OSSRH_GPG_SECRET_KEY_PASSWORD containing the password for your gpg secret key
3. Create a GitHub Actions step to install the gpg secret key
   1. Add an action similar to:

      - id: install-secret-key
        name: Install gpg secret key
        run: |
          # Install gpg secret key
          cat <(echo -e "${{ secrets.OSSRH_GPG_SECRET_KEY }}") | gpg --batch --import
          # Verify gpg secret key
          gpg --list-secret-keys --keyid-format LONG

   2. Verify that the secret key is shown in the GitHub Actions logs
   3. You can remove the output from list secret keys if you are confident that this action will work, but it is better to leave it in there
4. Bring it all together, and create a GitHub Actions step to publish
   1. Add an action similar to:

      - id: publish-to-central
        name: Publish to Central Repository
        env:
          MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
          MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
        run: |
          mvn \
            --no-transfer-progress \
            --batch-mode \
            -Dgpg.passphrase=${{ secrets.OSSRH_GPG_SECRET_KEY_PASSWORD }} \
            clean deploy

   2. After a couple of hours, verify that the artifact got published to The Central Repository

I'm facing below error:

Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7:deploy (injected-nexus-deploy) on project project-parent: Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7:deploy failed: Server credentials with ID "ossrh-user-in" not found! -> [Help 1]

Hi, maybe GH changed the way of dealing with envs/secrets but in my case \ns on the beginning of each line were causing an issue, without them all works great

Hi, maybe GH changed the way of dealing with envs/secrets but in my case \ns on the beginning of each line were causing an issue, without them all works great

Thanks for sharing.

Thanks @sualeh
It saved me a night :-)

This is appreciated.

HOWEVER: At time of writing this functionality is now build into the official setup-java action. Since you are more than likely to always need setup-java in your GitHub workflow there is no need anymore for the recipe in this gist.

Detailed instructions can be found HERE. One advantage to using GitHub's own action is that cleans up after itself, so that the private key is not leaked between jobs.

That's great news!

Thank you for sharing this. Very useful and succinct.