9.2 KiB
Release Checklist
This checklist will prepare v1.3.0
from v1.2.0
(minor release) or v1.3.1
from v1.3.0
(patch release). Adjust your version numbers accordingly.
Preparation
- Search the code for TODOs and FIXMEs that should be resolved before releasing.
- Update titles and labels for all PRs relevant for this release to aid in the changelog generation.
Automated release
Releases should be performed using the automated release pipeline.
Prepare temporary working branch
-
Create a temporary working branch to prepare the release. This branch should be based on main if preparing a minor release or be based on the existing release branch if it is a patch release.
ver=v1.3.1 # replace me minor=$(echo ${ver} | cut -d '.' -f 1,2) # optional suffix to add to the temporary branch name. Can be empty: suffix= suffix=/foo # if preparing a patch release, checkout existing release branch as base git checkout release/${minor} # if preparing a minor release, branch out from main instead git checkout main git pull working_branch=tmp/${ver}${suffix} git checkout -b ${working_branch} git push origin ${working_branch}
Patch release
-
cherry-pick
(only) the required commits frommain
- Check PRs with label needs-backport to find candidates that should be included in a patch release.
-
trigger the automated release pipeline from the working branch created above:
gh workflow run release.yml --ref ${working_branch} -F version=${ver} -F kind=patch
-
wait for the pipeline to finish
-
Check the s3proxy PR in the helm chart repository and approve it if things (esp. the version) look correct. Correct example for reference: https://github.com/edgelesssys/helm/pull/19/files
-
while in editing mode for the release, clear the textbox, select the last patch release for the current release branch and click "Generate release notes".
-
look over the autogenerated draft release. When fixing the changelog, prioritize updating the PR title/labels/description and regenerating the changelog over fixing things in the final changelog. The changelog should be primarily aimed at users. Rule of thumb: first part of the sentence should describe what changed for the user, second part can describe what has been changed to achieve this.
-
in the GitHub release UI, make sure the tag to create on release is set to
$ver
, and the target commit is set to the temporary release branch. -
publish.
Minor release
-
Merge ready PRs
-
trigger the automated release pipeline from the working branch created above:
gh workflow run release.yml --ref ${working_branch} -F version=${ver} -F kind=minor
-
wait for the pipeline to finish
-
upgrade the dogfooding cluster. Note that
upgrade check --update-config
will not yet show the new image. But you can manually set it in the config:./constellation upgrade check --update-config yq eval -i '.image="vX.YY.Z"' constellation-conf.yaml ./constellation config fetch-measurements ./constellation apply --yes --debug
Then wait until the node / Kubernetes upgrades are finished by periodically checking:
./constellation status
-
Check the s3proxy PR in the helm chart repository and approve it if things (esp. the version) look correct. Correct example for reference: https://github.com/edgelesssys/helm/pull/19/files
-
while in editing mode for the release, clear the textbox, select the last minor release and click "Generate release notes".
-
look over the autogenerated draft release. When fixing the changelog, prioritize updating the PR title/labels/description and regenerating the changelog over fixing things in the final changelog. The changelog should be primarily aimed at users. Rule of thumb: first part of the sentence should describe what changed for the user, second part can describe what has been changed to achieve this.
-
set the Target to
tmp/${ver}
-
in the GitHub release UI, make sure the tag to create on release is set to
$ver
, and the target commit is set to the temporary release branch. -
publish.
Post release steps
- Publish the provider release
- Merge the versioned docs PR
- Close fixed "known issues"
- Milestones management
- Create a new milestone for the next release
- Add the next release manager and an approximate release date to the milestone description
- Close the milestone for the release
- Move open issues and PRs from closed milestone to next milestone
- If the release is a minor version release, bump the pre-release version in the
version.txt
file. - Update the
fromVersion
ine2e-test-release.yml
ande2e-test-weekly.yaml
to the newly released version. To check the current values, run:grep "fromVersion: \[.*\]" -R .github
. - Reset
UpgradeRequiresIAMMigration
iniamupgrade.go
. - Write an email to STACKIT to inform them of the new relase. For this, you require the name and UUID of the release image. You can find the email address in our internal wiki:
export OS_CLOUD=stackit openstack image list | grep constellation # the output should look similar to this, where the first column is the UUID and the second column is the name # | 25edf48d-161f-452b-b420-963c3a80abd8 | constellation-stable-v2.16.4-qemu-vtpm | active |
Troubleshooting: Pipeline cleanup
No manual steps should be necessary anymore but in case you encounter issues, create a ticket to fix it. These are instructions to do some cleanup steps manually:
General
Depending on how far the pipeline ran we need to delete:
- the working branch (remove automated commits made by the process, keep any cherry picks)
- (only minor releases) the branch to merge changes back to main:
feat/release/v1.3.0
GCP
- Navigate to Images tab of the "constellation-images" project
- Search for the image versions "v1-3-0-gcp-sev-es-stable" and "v1-3-0-gcp-sev-snp-stable"
- Select the images and press "DELETE"
Azure
- Navigate to Azure compute galleries
- Select "Constellation_CVM" (this is for confidential vms on AMD SEV SNP)
- Select image definition "constellation"
- Select "Versions" submenu and search for "1.3.0"
- Press "Delete" button NEXT TO THE IMAGE VERSION TABLE. Do no delete the image definition.
AWS
Important: You need to repeat the following steps for every region supported by Constellation! Currently, this includes:
- Frankfurt (eu-central-1)
- Ireland (eu-west-1)
- Paris (eu-west-3)
- Ohio (us-east-2)
- Mumbai (ap-south-1)
Automated script
This is a script to automate the deletion but please be super careful to set the version correctly.
VERSION=vX.XX.X # !! DOUBLE CHECK CORRECTNESS!
regions=("eu-central-1" "eu-west-1" "eu-west-3" "us-east-2" "ap-south-1")
for region in "${regions[@]}"
do
aws ec2 describe-images --filters "Name=name,Values=constellation-$VERSION-aws-sev-snp" --query "Images[0].ImageId" --output text --region "$region" | xargs -I {{image_id}} aws ec2 deregister-image --image-id {{image_id}} --region "$region"
aws ec2 describe-snapshots --filters Name=tag:Name,Values=constellation-$VERSION-aws-sev-snp --query 'Snapshots[].SnapshotId' --output text --region "$region" | xargs -n 1 aws ec2 delete-snapshot --snapshot-id --region "$region"
aws ec2 describe-images --filters "Name=name,Values=constellation-$VERSION-aws-nitro-tpm" --query "Images[0].ImageId" --output text --region "$region" | xargs -I {{image_id}} aws ec2 deregister-image --image-id {{image_id}} --region "$region"
aws ec2 describe-snapshots --filters Name=tag:Name,Values=constellation-$VERSION-aws-nitro-tpm --query 'Snapshots[].SnapshotId' --output text --region "$region" | xargs -n 1 aws ec2 delete-snapshot --snapshot-id --region "$region"
done
Manual GUI steps
- Navigate to AMI
- Search for release version "constellation-v1.3.0" and select the AMIs for both variants ("constellation-v1.3.0-aws-sev-snp" and "constellation-v1.3.0-aws-nitro-tpm")
- On the "Actions" button (top right) select "Deregister AMI"
- Either follow the link on the deletion confirmation leading you to the Snapshots panel or navigate there yourself
- Search for a snapshot by the same name "constellation-v1.3.0" and select it
- On the "Actions" button (top right) select "Delete snapshot"