The following steps are to be followed when performing a full EKS Anywhere release (bundle + EKS-A CLI).
- release/triggers/bundle-release/development/BUNDLE_NUMBER
- release/triggers/bundle-release/development/CLI_MIN_VERSION
- release/triggers/bundle-release/development/CLI_MAX_VERSION
Merging this PR will trigger
- Builds of artifacts for all the upstream dependencies of EKS-A.
- Upload of artifacts and bundle manifest to the staging S3 bucket and public ECR repositories.
- release/triggers/bundle-release/production/BUNDLE_NUMBER
- release/triggers/bundle-release/production/CLI_MIN_VERSION
- release/triggers/bundle-release/production/CLI_MAX_VERSION
Merging this PR will trigger
- Download of artifacts from staging S3 bucket and public ECR repositories.
- Upload of artifacts and bundle manifest to the production S3 buckets and public ECR repositories.
Note: Since we carry out the bundle release first, it is possible that the CLI version mentioned in the CLI max version file has not been released yet. After a successful bundle release, we shall create a PR for the EKS-A CLI staging release, so we use the same version in the CLI max version file as the version we will eventually be releasing (the RELEASE_VERSION file below).
- release/triggers/eks-a-release/development/RELEASE_NUMBER
- release/triggers/eks-a-release/development/RELEASE_VERSION
Merging this PR will trigger
- Build of EKS Anywhere CLI from the branch specified.
- Integration test of the CLI with the previously released bundle manifest.
- Upload of CLI tarball and EKS-A releases manifest to the staging S3 bucket.
- release/triggers/eks-a-release/production/RELEASE_NUMBER
- release/triggers/eks-a-release/production/RELEASE_VERSION
Merging this PR will trigger
- Download of CLI tarball from the staging S3 bucket.
- Upload of CLI tarball and EKS-A releases manifest to the production S3 bucket.
Once we finish the production EKS-A release, we can mark the release accordingly on the repository.This includes adding a tag as well as a separate branch and updating our website to point to the new branch.
- Update the Changelog with changes for the release and rename
[Unreleased]
to the release version. - Tag the commit with the release version (ex.
v0.6.0
). - Create a branch from the tag
- Have one of the maintainers, who has access to the infrastructure cdk package, change the website configuration to point to the newly created branch
- Add a file to the branch called
PUBLISHED_VERSION
to trigger a change to the infrastructure to deploy the new changes
Now the homepage for EKS-A should be updated with the changes from this new branch