Wanaku Release Guide

Automated Release Process

Releases are cut from release branches following the X.Y.x naming convention (e.g., 0.1.x, 0.2.x).

Create the release branch (first release of a minor version only)

git checkout main
git checkout -b 0.2.x
git push origin 0.2.x

Set the versions

export RELEASE_BRANCH=0.1.x
export PREVIOUS_VERSION=0.1.2
export CURRENT_DEVELOPMENT_VERSION=0.1.3
export NEXT_DEVELOPMENT_VERSION=0.1.4

Trigger the release

gh workflow run release -r ${RELEASE_BRANCH} -f releaseBranch=${RELEASE_BRANCH} -f previousDevelopmentVersion=${PREVIOUS_VERSION} -f currentDevelopmentVersion=${CURRENT_DEVELOPMENT_VERSION} -f nextDevelopmentVersion=${NEXT_DEVELOPMENT_VERSION}

NOTE

The -r flag tells GitHub to run the workflow from the release branch. The releaseBranch input tells the workflow which branch to check out and push version bump commits to.

The release build can take up to 30 minutes to complete. This will:

1. Validate the artifacts
2. Publish the files to the Maven Central.

IMPORTANT

It is absolutely mandatory for the artifacts to be validated for the release to proceed.

The publication to Maven Central should take another 30 minutes.

In the meantime, you can release the artifacts. This will build the zip files and tarballs with each component, the native executables and also will publish the containers to Quay.

gh workflow run release-artifacts -f currentDevelopmentVersion=${CURRENT_DEVELOPMENT_VERSION}

After this is completed successfully, you can announce the release.

Early Builds

To release early builds, run:

gh workflow run early-access -f currentDevelopmentVersion=$(cat core/core-util/target/classes/version.txt)

Manual Release Process

Prepare the environment

• Tools required: GraalVM, jreleaser, gpg (with your keys installed and available) and Apache Maven.
• Hardware: Linux (x86 64) and macOS (aarch64)

Keys

Make sure you have your GPG keys installed. You can check with the following command:

gpg --list-public-keys --keyid-format LONG

NOTE

Make sure the configuration file is stored securely and not accessible by others.

Before start

Repeat this for every machine to be used for the release. Make sure you are on the release branch.

export RELEASE_BRANCH=0.2.x
git checkout ${RELEASE_BRANCH}
export PREVIOUS_VERSION=0.1.0
export CURRENT_DEVELOPMENT_VERSION=0.2.0
export NEXT_DEVELOPMENT_VERSION=0.2.1

NOTE

There is no need to add -SNAPSHOT to the versions.

Pre-Release Checks / Dry Run

NOTE

The steps assume you are primarily building on macOS, with a secondary step on a x86-64 Linux machine.

Build the project

mvn -Pdist -Dnative clean package

Then, check if the build can be released.

NOTE: make sure to replace the version with the actual version you are building.

jreleaser full-release -Djreleaser.project.version=${CURRENT_DEVELOPMENT_VERSION}-SNAPSHOT --select-platform=osx-aarch_64 --dry-run

Then, on your Linux host, build the project again and check if Linux artifacts can be released.

jreleaser full-release -Djreleaser.project.version=${CURRENT_DEVELOPMENT_VERSION}-SNAPSHOT --select-platform=linux-x86_64 --dry-run --exclude-distribution=cli --exclude-distribution=router --exclude-distribution=service-kafka --exclude-distribution=service-http --exclude-distribution=provider-file --exclude-distribution=service-yaml-route --exclude-distribution=provider-ftp --exclude-distribution=service-sqs --exclude-distribution=service-telegram

If everything goes alright, then it should be ready to release.

Release Maven artifacts

mvn release:clean
mvn --batch-mode -Dtag=wanaku-${CURRENT_DEVELOPMENT_VERSION} release:prepare -DreleaseVersion=${CURRENT_DEVELOPMENT_VERSION} -DdevelopmentVersion=${NEXT_DEVELOPMENT_VERSION}-SNAPSHOT

Adjust the Jbang catalog file:

sed -i -e "s/$PREVIOUS_VERSION/$CURRENT_DEVELOPMENT_VERSION/g" jbang-catalog.json

Commit the auto-generated UI files and the other version-specific files:

mvn -PcommitFiles scm:checkin

NOTE

Do not perform any other manual commit nor push the code. If necessary, append to the UI commit.

Erase the tag created incorrectly by Maven

git tag -d wanaku-${CURRENT_DEVELOPMENT_VERSION}

Recreate the release tag by marking tagging at exactly two commits before HEAD (i.: ignoring the version bumps from maven)

git tag wanaku-${CURRENT_DEVELOPMENT_VERSION} HEAD~2

Push the version bump commits to the release branch and the tag:

git push upstream HEAD:${RELEASE_BRANCH} wanaku-${CURRENT_DEVELOPMENT_VERSION}

Now continue with the release:

mvn -Pdist release:perform

After the upload is complete, go to Maven Central and publish the deployment.

[NOTE] As of 0.1.0, this should be done automatically, but double check on Maven Central.

Native Artifacts

Publish the native artifacts for macOS (aarch64)

Now, build the native artifacts for macOS (aarch64) and publish them on GitHub.

mvn -Pdist -Dnative clean package

Perform a dry-run to check if everything is OK:

jreleaser full-release -Djreleaser.project.version=${CURRENT_DEVELOPMENT_VERSION} --select-platform=osx-aarch_64 --dry-run

If everything is OK, then publish:

jreleaser full-release -Djreleaser.project.version=${CURRENT_DEVELOPMENT_VERSION} --select-platform=osx-aarch_64

Publish the native artifacts for Linux (x86 64)

NOTE: this guide assumes the main build was performed on a macOS.

If you are not running this on the machine where you cut the release, then fetch the tags

git fetch --all --tags && git checkout wanaku-${CURRENT_DEVELOPMENT_VERSION}

Now, build the native artifacts for Linux (x86 64):

mvn -Pdist -Dnative clean package

Check if all went well with a dry-run:

jreleaser full-release -Djreleaser.project.version=${CURRENT_DEVELOPMENT_VERSION} --select-platform=linux-x86_64 --exclude-distribution=cli --exclude-distribution=router --exclude-distribution=service-kafka --exclude-distribution=service-http --exclude-distribution=provider-file --exclude-distribution=service-yaml-route --exclude-distribution=provider-ftp --exclude-distribution=service-sqs --exclude-distribution=service-telegram --exclude-distribution=service-exec --exclude-distribution=service-tavily --exclude-distribution=provider-s3 --dry-run

Then, run jreleaser filtering the source ones, and only publishing the Linux native deliverables on GitHub.

jreleaser full-release -Djreleaser.project.version=${CURRENT_DEVELOPMENT_VERSION} --select-platform=linux-x86_64 --exclude-distribution=cli --exclude-distribution=router --exclude-distribution=service-kafka --exclude-distribution=service-http --exclude-distribution=provider-file --exclude-distribution=service-yaml-route --exclude-distribution=provider-ftp --exclude-distribution=service-sqs --exclude-distribution=service-telegram --exclude-distribution=service-exec --exclude-distribution=service-tavily --exclude-distribution=provider-s3

Containers

This process is automated, but if there is a need to run it manually, then it can be done using the following:

mvn -Pdist -Dquarkus.container-image.build=true -Dquarkus.container-image.push=true clean package

NOTE

You must be logged in in Quay.io with the Podman (preferred) or Docker CLI.