This document describes how to release this component.
The component is released using GitHub automation.
At a high level, the process is as follows:
- The developer prepares the release blog post.
- The developer adds their private key/passphrase as repository secrets
- The workflow
stage_release
tags, builds/signs the release, and stages the release on a Nexus staging repository. This process uses the GitHub machine account kroxylicious-robot and a user token owned by Sonatype accountkroxylicious
account. - The stage release is verified using manual verification steps.
- The release is made public.
- The developer removes their private key/passphrase from the repository secrets.
You must be a member of the Kroxylicious release-engineers and have access to create secrets within the kroxylicious repository.
You will need a GPG key, follow this guide.
You will need to upload your GPG public key to some keyservers. You can follow this which explains how to obtain your public key. Upload that key to the following keyservers:
Create-or-update the following repository secrets:
Secret | Description |
---|---|
KROXYLICIOUS_RELEASE_PRIVATE_KEY |
Private key, in armor format, of the project admin conducting the release. |
KROXYLICIOUS_RELEASE_PRIVATE_KEY_PASSPHRASE |
Passphrase used to protect the private key |
To export your key run something like
gpg --armor --export-secret-key ${KEY_ID} | pbcopy
While pbcopy
is macOS specific, similar utilities exist for Linux see StackExchange
Prepare the release blog post by opening a PR [kroxylicious.github.io](https://github.com/kroxylicious/kroxylicious.github.io. Get the PR reviewed by your peers, addressing any comments, until the content is agreed. Don't merge it yet.
Use the Kroxylicious Team Developers Slack Channel to coordinate the release with the other developers. It is important no other work is merged to main during the release.
Run stage_workflow.
Set the release-version
argument to the version being release e.g. 0.7.0
.
This will:
- raise single PR that will contain two commits:
- the first will version the artefacts at
release-version
. Arelease-version
tag will point at this commit. - the second will re-open main for development, at the next snapshot.
- the first will version the artefacts at
- stage a release Nexus UI. It'll be named
iokroxylicious-nn
.
If anything goes wrong, follow the steps in Failed Releases
You can validate the staged artefacts by using a test application, T
, use the Maven artefacts. The kroxylicious-wasm from the
community-gallery is a suitable choice.
- Find the staging repository URL by executing.
The repository url should include
curl -sS --header 'Accept: application/json' \ https://s01.oss.sonatype.org/service/local/all_repositories \ | jq '.data[] | select(.name | contains("kroxylicious")) | .contentResourceURI'
iokroxylious-nn
. You can also browse to it via the Nexus UI. - Add a
<repositories>
that references the staging repository public url toT
's POM. - Update
T
's kroxylicious dependency to refer to the<RELEASE_VERSION>
. - Run
T
build/test cycle but use an alternative cache location to be sure artefacts are being fetched. Check the build output, you'll see the kroxylicious comes from the staging location.
MAVEN_OPTS="-Dmaven.repo.local=/tmp/repository" mvn verify
If the build passes, proceed to make the release public.
The local changes made to T
's POM can be reverted.
- Comment on the PR
@kroxylcious-robot promote-release
. - Let Kroxylicious Team Developers know the release is finished.
- Publish the documentation for the release
- Merge the blog post PR
- Post to social media about the release.
If anything goes wrong, follow the steps in Failed Releases
If the release fails verification, comment on the PR @kroxylcious-robot drop-release
.
This will drop the snapshot repository, delete the release notes and close PR.
Update the private key/passphrase secrets from the repository secrets to whitespace.