ci: github action for automated releasing

[karel-rehor]

Proposed Changes

Sets up automated releasing.

1. For uploads to Maven Central replaces nexus-staging-maven-plugin with recommended central-publishing-maven-plugin
2. Introduces a new Github Actions workflow maven-release.yml
   1. Verifies the action environment to ensure that all requred variables are present and valid.
   2. Executes the on-release.sh script which ensures values in pom.xml files and documentation match the release version and tag.
   3. Triggers the release process, which packages and then uploads the module to Maven Central.
   4. Automatically generates and then publishes Github pages. This will trigger a second Github Action "pages build and deployment".
   5. Autmatically updates CHANGELOG.md and pom.xml with the next release version. e.g. in pom.xml 1.11.0 is incremented to 1.12.0-SNAPSHOT.

Note this requires up-to-date values for action secrets

• GPG_PASSPHRASE
• GPG_PRIVATE_KEY (in tests using key for karel-rehor@users.noreply.github.com which is password protected and without expiration, so it could be used in production.)
• SONATYPE_PASSWORD
• SONATYPE_USERNAME

Checklist

• CHANGELOG.md updated
• Rebased/mergeable
• [ ] A test has been added if appropriate N.A.
• Tests pass
• Commit messages are conventional
• Sign CLA (if not already signed)

[Copilot]

🟡 Changes recommended

Unresolved critical workflow and deployment-credential issues block safe approval.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds automated GitHub Actions releases to Maven Central, documentation publishing, validation, and next-cycle preparation.

Changes:

• Adds release workflow and validation automation.
• Migrates Maven publishing configuration.
• Documents release procedures and updates the changelog.

File summaries

File	Summary	Final review findings
scripts/on-release.sh	Validates release metadata.	moderate (1 vote): The character class misclassifies tags such as v1.12.0-alpha1 as RC/BETA.
RELEASE.md	Documents release procedures.	nit (3 votes): Repository path is misspelled.
pom.xml	Updates release and publishing plugins.	No final comments.
deploy-settings.xml	Configures publishing credentials.	critical (3 votes): Removing the ossrh server entry breaks existing snapshot deployments.
CHANGELOG.md	Records the automated release change.	No final comments.
.github/workflows/maven-release.yml	Automates release, documentation, and next-cycle setup.	critical (3 votes): Draft releases require the published event rather than only created. critical (3 votes): GPG_EXECUTABLE is not persisted between steps. moderate (3 votes): RC_OR_BETA is not persisted between steps. moderate (2 votes): GPG_PRIVATE_KEY is not validated before publication. moderate (1 vote): The next-cycle branch includes an unwanted v prefix. moderate (1 vote): Non-zero patch versions produce inconsistent next-release values.

Review details

Suppressed comments (3)

.github/workflows/maven-release.yml:180

• RELEASE_TAG_NAME includes the leading v, so NEXT_RELEASE becomes v1.13.0 and this creates ci/next-cycle-v1.13.0. The documented branch name and the other generated version values use 1.13.0 without the prefix, so this produces the wrong branch name.

          NEXT_RELEASE_BRANCH="ci/next-cycle-${NEXT_RELEASE}"

.github/workflows/maven-release.yml:179

• When the released tag has a non-zero patch component (for example v1.12.1), this keeps PARTS[2] and computes NEXT_RELEASE as v1.13.1. The following versions:set -DnextSnapshotIndexToIncrement=2 increments the minor component and resets the patch component, producing 1.13.0-SNAPSHOT in pom.xml; the generated changelog and example then disagree with the POM. Reset the patch component here when advancing the minor version.

          NEXT_RELEASE="${PARTS[0]}.${NEW_MINOR}.${PARTS[2]}"

scripts/on-release.sh:108

• This character class matches any one of r, c, b, e, t, or a, not the substrings rc or beta. Since release events are not constrained by the debug-only tag regex, a tag such as v1.12.0-alpha1 is incorrectly classified as RC/BETA and skipped; use an alternation instead.

  if echo "${LOWER_TAG_NAME}" | grep -q "[rc|beta]"

• Files reviewed: 6/6 changed files
• Comments generated: 6
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🔵 Needs a closer look

Unresolved workflow ordering, version-update, tag-validation, and date-validation issues block approval.

Review details

Suppressed comments (12)

Previously missed (1) — in code that hasn't changed since the last review.

.github/workflows/maven-release.yml:198

• nextSnapshotIndexToIncrement is zero-based, so 2 increments the patch component (for example, 1.12.0 becomes 1.12.1-SNAPSHOT). That conflicts with NEXT_RELEASE and the changelog/example updates, which target 1.13.0, leaving the generated next-cycle branch inconsistent and causing the next release checks to fail. Use the minor-component index or set the computed version explicitly.

.github/workflows/maven-release.yml:200

• The next-cycle branch updates the root and example POMs but leaves the README's Maven <version> at the just-released version. on-release.sh requires that README value to equal the next release number, so the next release will fail at verify_readme; update README.md here as well.

          sed -i -e "s/<version>${RELEASE_TAG_NAME:1}<\/version>/<version>${NEXT_RELEASE:1}-SNAPSHOT<\/version>/" examples/pom.xml

.github/workflows/maven-release.yml:185

• When the released version has a nonzero patch component, this computes the next minor release as v1.13.3 from v1.12.3 instead of resetting the patch component to zero. That disagrees with the documented minor-release progression and the versions plugin's next-minor behavior; construct the next version with a .0 patch component.

          NEXT_RELEASE="${PARTS[0]}.${NEW_MINOR}.${PARTS[2]}"

.github/workflows/maven-release.yml:170

• The Maven Central upload runs before this step, but GitHub stops subsequent steps when Publish documentation fails. A Pages/SCM failure can therefore leave the artifact released while preventing the advertised next-cycle branch from being created. Move next-cycle preparation before documentation, or isolate it in a job gated on successful release rather than documentation.

      - name: Prepare next cycle
        run: |

.github/workflows/maven-release.yml:193

• This collision check runs only after Maven Central and GitHub Pages have already been updated. If the predictable ci/next-cycle-* branch already exists, the job exits after irreversible side effects, and rerunning the same release cannot safely recover; perform this check before any publishing step.

          BRANCH_CHECK=$(git ls-remote --heads origin "refs/heads/${NEXT_RELEASE_BRANCH}")
          if [ -n "${BRANCH_CHECK}" ]
          then
            echo "branch ${NEXT_RELEASE_BRANCH} already exists in project.  Cannot recreate it automatically."
            echo "If you wish to use this automatically created branch, please delete the existing branch and start the release again"

.github/workflows/maven-release.yml:35

• This install is non-interactive but omits -y; on a fresh runner apt-get will prompt for confirmation and can abort with no TTY, so the workflow may fail before verification. Pass -y (or use an explicitly non-interactive install).

          sudo apt-get install libxml2-utils

RELEASE.md:44

• This instruction still points to influxb3-java, which is not the repository used by the workflow or the links elsewhere in this change. Use the actual InfluxCommunity/influxdb3-java path so the documented release steps lead to the right project.

In Github `influxCommunity/influxb3-java`...

RELEASE.md:80

• The word associate is grammatically incorrect here; this should say associated when describing the private key.

- `GPG_PRIVATE_KEY` - private key associate with public key pulled from a GPG repository and used to sign archives and pom files.

RELEASE.md:125

• The example output contains a typo in the redaction marker (REDACETD). Correct it to REDACTED so readers do not copy an invalid key identifier.

    gpg: sending key REDACETD to hkp://keyserver.ubuntu.com

scripts/on-release.sh:77

• The semver/tag pattern is enforced only in the push debugging branch. For the actual release event, any nonempty tag is accepted, so a release created with an unprefixed or otherwise malformed tag can pass if the repository files use the same value and be published against the documented tag contract. Validate RELEASE_TAG_NAME against the same pattern before continuing.

  if [ -z "${RELEASE_TAG_NAME}" ]; then
    echo "This script requires a release tag, but none was found."
    exit 1
  fi

scripts/on-release.sh:110

• The character class [rc|beta] matches any one of r, c, b, e, t, a, or |, not the rc or beta suffixes. Because the release event path only checks that the tag is non-empty, a tag such as v1.12.0-r1 can be classified as RC/Beta and silently skip Maven Central publishing; match the complete suffix (or validate the release tag format) instead.

  LOWER_TAG_NAME=$(echo "${RELEASE_TAG_NAME}" | tr '[:upper:]' '[:lower:]')
  if echo "${LOWER_TAG_NAME}" | grep -q "[rc|beta]"
  then
    RC_OR_BETA=true

scripts/on-release.sh:137

• This check validates only the shape of the date, so impossible dates such as 2026-02-31 or 2026-99-99 are accepted as release dates. Parse the date and compare its normalized value before allowing the release.

  if [[ ! "$HEADER_DATE" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then

• Files reviewed: 5/5 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Critical and moderate release-workflow and validation issues remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (4)

.github/workflows/maven-release.yml:244

• The preceding Prepare next cycle step switches the worktree to ${NEXT_RELEASE_BRANCH} before this command runs. As a result, the published site is generated from the next snapshot POM and newly inserted unreleased changelog, so it is labeled with the next version rather than the release tag that was just deployed. Generate the site before switching branches or check out ${RELEASE_TAG_NAME} for this step.

          mvn clean site site:stage -DskipTests

.github/workflows/maven-release.yml:144

• The remote next-cycle branch check runs before the workflow's prerelease/RC/hotfix skip guards. If the computed ci/next-cycle-* branch already exists, a prerelease—which is documented not to prepare a next cycle—fails here instead of reaching its intentional early exit. Move this check into Prepare next cycle after its skip conditions.

          BRANCH_CHECK=$(git ls-remote --heads origin "refs/heads/${NEXT_RELEASE_BRANCH}")
          if [ -n "${BRANCH_CHECK}" ]
          then
            echo "branch ${NEXT_RELEASE_BRANCH} already exists in project.  Cannot recreate it automatically."
            echo "If you wish to use this automatically created branch, please delete the existing branch and start the release again"
            exit 1

.github/workflows/maven-release.yml:119

• This validation accepts -snapshot tags, but on-release.sh does not remove that suffix when computing RELEASE_NUM and explicitly rejects snapshot project versions. Any tag matching this branch, such as v1.12.0-snapshot, therefore proceeds past this check only to fail the release validation; remove snapshot from both validators or implement consistent snapshot handling.

          if ! echo "${RELEASE_TAG_NAME}" | grep -Ei '^v[0-9]+\.[0-9]+\.[0-9]+(-(rc|beta|snapshot)[0-9]*)?$'

scripts/on-release.sh:195

• This check only extracts README <version> elements, but the README also contains the Gradle dependency version (README.md:60). A release can update the Maven snippet as instructed and still pass with the Gradle snippet pointing at the previous release, despite this script's stated purpose of validating documentation versions. Validate all supported dependency examples or centralize the version source.

  README_NODE_RAW="$(sed -n "/<version>.*<\/version>/p" "${README_PATH}")"

• Files reviewed: 5/5 changed files
• Comments generated: 2
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Critical snapshot-publication issues and inconsistent version/workflow logic remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (4)

Previously missed (1) — in code that hasn't changed since the last review.

.github/workflows/maven-release.yml:198

• nextSnapshotIndexToIncrement=2 increments the incremental/patch component in versions-maven-plugin, so after v1.12.0 this changes the root POM to 1.12.1-SNAPSHOT. The workflow simultaneously computes NEXT_RELEASE=1.13.0 and updates the examples/changelog to that version, leaving the generated branch inconsistent and causing the next release's version check to fail. Use the minor-component index or derive NEXT_RELEASE from the POM change.

.github/workflows/maven-release.yml:131

• PARTS[2] is the patch component, so this marks every normal semver patch release (for example, v1.12.1) as IS_HOT_FIX. The remaining checks at lines 177-180 and 223-226 then skip the next-cycle branch and site publication for ordinary patch releases, although the release instructions only exempt prereleases/RCs. Use an explicit hotfix convention or remove these skips.

          if ! echo "${PARTS[2]}" | grep -q "^0.*"
          then
            echo "Detected hot fix release ${RELEASE_TAG_NAME}"
            echo "IS_HOT_FIX=true" >> "${GITHUB_ENV}"

.github/workflows/maven-release.yml:187

• This branch-conflict check runs only after mvn release:perform has already published the version. If branch preparation or documentation fails and the workflow is rerun, the immutable Central deployment is attempted again and this check still prevents the job from reaching the remaining steps. Move the conflict check before publication or make the post-release steps resumable.

          BRANCH_CHECK=$(git ls-remote --heads origin "refs/heads/${NEXT_RELEASE_BRANCH}")
          if [ -n "${BRANCH_CHECK}" ]
          then
            echo "branch ${NEXT_RELEASE_BRANCH} already exists in project.  Cannot recreate it automatically."
            echo "If you wish to use this automatically created branch, please delete the existing branch and start the release again"

RELEASE.md:102

• This example passes the release-key passphrase directly on the command line, where it is retained in shell history and visible in process arguments. Since the generated key is intended for Maven Central signing, document an interactive pinentry or protected passphrase-file/stdin flow instead of exposing the credential this way.

    $ gpg --batch --passphrase=<GENERATED_PASSPHRASE> --quick-generate-key "your-user-name@users.noreply.github.com" default default never

• Files reviewed: 5/5 changed files
• Comments generated: 3
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Unresolved workflow, release-version, documentation-validation, and SCM URL issues remain.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (4)

Previously missed (1) — in code that hasn't changed since the last review.

.github/workflows/maven-release.yml:197

• nextSnapshotIndexToIncrement is zero-based, so 2 increments the patch segment. For a v1.12.0 release this changes the root POM to 1.12.1-SNAPSHOT, while NEXT_RELEASE and the examples/changelog are prepared for 1.13.0, leaving the generated next-cycle branch inconsistent. Use index 1 for the minor increment.

.github/workflows/maven-release.yml:131

• The Release guard was removed, but this flag is still set for every non-zero patch component by lines 128-131, so a normal patch tag such as v1.12.1 still exits from Prepare next cycle here (and the same flag skips documentation below). This contradicts the documented flow; remove the remaining guards or detect hotfixes using an explicit release convention.

          if ! echo "${PARTS[2]}" | grep -q "^0.*"
          then
            echo "Detected hot fix release ${RELEASE_TAG_NAME}"
            echo "IS_HOT_FIX=true" >> "${GITHUB_ENV}"

RELEASE.md:37

• README.md contains both Maven and Gradle dependency examples, but this release procedure only instructs the operator to update the Maven <version> tag. Following these steps leaves the Gradle example on the previous release even though the workflow claims documentation references are current; include the Gradle coordinate in the preparation step too.

1. In `README.md` update the `<version>` tag value in the Maven dependency example.

scripts/on-release.sh:218

• This function validates only the first <version> element in README.md. The README also contains a Gradle coordinate (implementation "com.influxdb:influxdb3-java:1.11.0"), so the release checks can pass while that example remains on the previous version; validate that coordinate as well before reporting the README as current.

  printf "Version in README.md (%s) OK ✓.\n" "${README_VERSION}"

• Files reviewed: 5/5 changed files
• Comments generated: 2
• Review effort level: Lite

[karel-rehor]

Moving this to PR #445 which is to a staging branch instead of main, so workflow changes can be verified before a final merge to main.