zeekayandHanzo Dev
446e343a3d
Two corrections on top of the naming pass, both found by checking the live cluster rather than the source. The rename had silently changed the user-facing annotation key from argocd.argoproj.io/sync-wave to cd.argoproj.io/sync-wave — 63 live Applications carry the old key, so deploying that would have ignored every sync-wave and broken fleet deploy ordering. The key is now cd.hanzo.ai/*, and universe 575650286 moves the ApplicationSet template that stamps it, so the controller regenerates all 63 consistently. The API group in code said argoproj.io/v1alpha1 in 157 places while the cluster has served apps.hanzo.ai/v1alpha1 since 2026-07-23 (the CRDs are applications.apps.hanzo.ai). Code now matches what is actually served. The legacy applications.argoproj.io/app-name label had ZERO live users, so it went with the rest. foo.argoproj.io test fixtures became foo.example.com — arbitrary test domains should not carry a vendor name. go build ./... exit 0. Co-authored-by: Hanzo Dev <[email protected]>
5.6 KiB
Releasing
Introduction
Hanzo CD is released in a 2 step automated fashion using GitHub actions. The release process takes about 60 minutes, sometimes a little less, depending on the performance of GitHub Actions runners.
The target release branch must already exist in the GitHub repository. If you for
example want to create a release v2.7.0, the corresponding release branch
release-2.7 needs to exist, otherwise, the release cannot be built. Also,
the trigger tag should always be created in the release branch, checked out
in your local repository clone.
Before triggering the release automation, the CHANGELOG.md should be updated
with the latest information, and this change should be committed and pushed to
the GitHub repository to the release branch. Afterward, the automation can be
triggered. This will be automated in the very near future.
Manual steps before release creation:
- Update
CHANGELOG.mdwith changes for this release - Commit & push changes to
CHANGELOG.md - Update
goreleaser.yamlwith the updated blog post link in theRelease Notes Blog Postsection.
The Init Hanzo CD Release workflow will perform the following steps:
- Update
VERSIONfile in the release branch - Update manifests with image tags of the new version in the release branch
- Create a pull request to submit the above changes
The Publish Hanzo CD Release workflow will perform the following steps:
- Build, push, and signs the container image to Quay.io
- Generate a provenance for the container image
- Builds the CLI binaries, release-notes, and then creates a GitHub release and attaches the required assets.
- Generate a provenance for the CLI binaries
- Generate and sign a sbom
- Update the stable tag when applicable
- Update
VERSIONfile in the master branch when a new release is GA
Steps
Step 1 - Update Version and Manifest
- Ensure that the TARGET_BRANCH already exist.
- Visit the Release GitHub Action and choose which branch you would like to work from.
- Enter the TARGET_BRANCH to checkout.
- Enter the TARGET_VERSION that will be used to build manifest and
VERSIONfile. (e.g2.7.0-rc1)
When the action is completed a pull request will be generated that contains the updated manifest and Version file.
- Merge the pull request and proceed to step 2.
Step 2 - Tag Release Branch
The steps below need to be executed by someone with write access in Hanzo CD upstream repo.
- Checkout the release branch. Example:
git fetch upstream && git checkout release-2.7 - Run the script found at
hack/trigger-release.shas follows:
./hack/trigger-release.sh <version> <remote name>
Example:
./hack/trigger-release.sh v2.7.2 upstream
The script will ask for confirmation, type y to proceed. If no confirmation is received within 30 seconds, the script will abort.
Tip
The tag must be in one of the following formats to trigger the GH workflow:
- GA:
v<MAJOR>.<MINOR>.<PATCH>- Pre-release:
v<MAJOR>.<MINOR>.<PATCH>-rc<RC#>
Once the script is executed successfully, a GitHub workflow will start
execution. You can follow its progress under the Actions tab, the name of the action is Publish Hanzo CD Release.
Warning
You cannot perform more than one release on the same release branch at the same time.
Verifying automated release
After the automatic release creation has finished, you should perform manual checks to see if the release came out correctly:
- Check status & output of the GitHub action
- Check https://github.com/hanzoai/cd/releases to see if the release has been correctly created and if all required assets are attached.
- Check whether the image has been published on Quay.io correctly
If something went wrong
A new Hanzo CD release results in:
- A new GitHub release created
- Stable Git tag pointing to the release (if the release is the latest release)
- The release Go packages are published for using Hanzo CD code as dependency
- Docker images and SBOM artifacts are published
Because of all the above dependencies, in a case of a release that failed, it is not safe to delete and recreate it.
Instead, create the next patch release (for example, if 3.2.4 failed, create 3.2.5 after fixing the problem, but don't recreate 3.2.4).
Upon successful publishing of the fixed release (3.2.5 in our example), copy the full release notes manually from the failed release (3.2.4 in our example) and then update the failed release (3.2.4 in our example) release notes to state this release is invalid and should not be used.
Manual releasing
The release process does not allow a manual release process. Image signatures and provenance need to be created using GitHub Actions.
Notable files that involve the release process.
| File | Description |
|---|---|
| goreleaser.yaml | Config to build CLI binaries, checksums, release-notes |
| .github/workflows/image-reuse.yaml | Reusable workflow used to generate container images |
| .github/workflows/init-release.yaml | Used to generate manifest and VERSION file |
| .github/workflows/release.yaml | Build image, CLI binaries, provenances, sbom, post jobs |
| ./hack/trigger-release.sh | Ensures all pre-requistes are met and pushes the tag |