configured automated releases

[aalmiray]

Adds a GH workflow for triggering a release on demand. Adds JReleaser for creating a Git releases.

Requires the following repository secrets:

• SONATYPE_USERNAME: username required for publication to OSSRH
• SONATYPE_PASSWORD: password required for publication to OSSRH
• GPG_PASSPHRASE: GPG passphrase
• GPG_PRIVATE_KEY: ASCII armored GPG secret key

[amaembo]

@aalmiray thanks! Can I test it without actually releasing (e. g., release a snapshot)?

[amaembo]

Also:

Why do we need these lines for the 'Setup Java' step? I don't think I need any kind of authentication for Java setup.

      server-username: MAVEN_USERNAME
      server-password: MAVEN_CENTRAL_TOKEN
      gpg-private-key: ${{ secrets.GPG_PRIVATE_KEY }}
      gpg-passphrase: MAVEN_GPG_PASSPHRASE

And where does the email '"41898282+github-actions[bot]@users.noreply.github.com"'come from? In particular, this '41898282' number? What is it?

During the release, I usually update manually README.md, incrementing the version number there. Also, I have a separate pom.xml for benchmarks with synchronized version number. That pom.xml is never released and used just to run benchmarks. Can we update version numbers automatically there as well?

[amaembo]

To protect my identity better, I'd prefer to type GPG_PASSWORD manually every time I release a new version. It's very strange to store both GPG_PRIVATE_KEY and GPG_PASSWORD in the same place. Is it possible to make this variable a workflow input parameter?

[amaembo]

I updated the workflow to ask GPG_PASSPHRASE (hopefully I did it correctly). When I tried to run it, it says:

  ./mvnw --no-transfer-progress -B --file pom.xml verify
  shell: /usr/bin/bash -e {0}
  env:
    JAVA_HOME: /opt/hostedtoolcache/Java_Zulu_jdk/11.0.13-8/x64
/home/runner/work/_temp/471edf30-7825-4f62-b0f5-a92e68e64608.sh: line 1: ./mvnw: No such file or directory

[amaembo]

Replaced ./mvnw with mvn and copied "Setup java" step from my test.yml workflow #TryingRandomStuffUntilItWorks. Also, I split set-version and commit-version steps and put verify in-between, so if verify fails, we don't have an unwanted commit.

Still GPG fails. Investigating...

[aalmiray]

@amaembo you can test JReleaser locally by running with the -Djreleaser.dryrun=true flag. You'll need a Personal Access Token (https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) with write permissions only (the default). Store it in a env var named JRELEASER_GITHUB_TOKEN, or in a config file (default is /.jreleaser/config.properties)

[aalmiray]

Why do we need these lines for the 'Setup Java' step? I don't think I need any kind of authentication for Java setup.

This is per the documentation of setup-java, required to configure the settings.xml file https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#Publishing-using-Apache-Maven

And where does the email '"41898282+github-actions[bot]@users.noreply.github.com"'come from? In particular, this '41898282' number? What is it?

These are the identity coordinates of the default "GitHub Actions bot". You can substitute this with any values you want. If you prefer to keep these values somewhwt private (they'll be part of the commit anyway) then use repository secrets.

It's not possible to supply a password manually when the GH workflow is running. If this is a big concern for you then you won't be able to use the GH workflow to post a release. In this case you may continue releasing to Maven Central just like you've done so far. After releasing to Maven Central you can create a Git release with JReleaser also from your local environment, the only important thing to remember is that you do need JRELEASER_GITHUB_TOKEN to be set.