Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update kustomize templates only after verifying images are available in registries #995

Merged
merged 1 commit into from
Jul 29, 2021
+28 −15
Merged

Update kustomize templates only after verifying images are available in registries #995

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 28 additions & 15 deletions docs/RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,9 +1,7 @@
# Amazon Elastic Block Store (EBS) CSI driver Release Process

NOTE: Your GitHub account must have the required permissions and you must have generated a GitHub token.

## Choosing the release version

Using semantic versioning, pick a release number that makes sense by bumping the major, minor or patch release version. If its a major or minor release (backwards incompatible changes, and new features, respectively) then you will want to start this process with an alpha release first. Here are some examples:

Bumping a minor version after releasing a new feature:
Expand All @@ -29,14 +27,14 @@ v1.6.2 -> v2.0.0-alpha.0
```

## Choosing the release branch
You also might need to create a release branch, if it doesn't already exist, if this release requires backporting changes to an older major or minor version. For example, in the case that we are backporting a fix to the v0.5 release branch, and we have a v0.6 release branch (which we don't at the time of writing), then we would do the following:
You also might need to create a release branch, if it doesn't already exist. For example, in the case that we are backporting a fix to the v0.5 release branch, then we would do the following:

1. Create the release branch (named release-0.5) if it doesn't exist from the last v0.5.x tagged release (or check it out if it already exists).
1. Create the release branch (named release-0.5) if it doesn't exist or check it out if it already exists.
2. Cherry-pick the necessary commits onto the release branch.
3. Follow the instructions below to create the release commit.
4. Create a pull request to merge your fork of the release branch into the upstream release branch (i.e. <user>/aws-ebs-csi-driver/release-0.5 -> kubernetes-sigs/aws-ebs-csi-driver/release-0.5).

## Create the release commit
## Create the release commit in the release branch

### Generate the CHANGELOG
We need to generate the CHANGELOG for the new release by running `./hack/release`. You need to pass previous release tag to generate the changelog.
Expand All @@ -50,19 +48,16 @@ This will print the CHANGELOG to stdout. You should create a new section for the
### Update the README
Search for any references to the previous version on the README, and update them if necessary.

### Update the build and deployment files
### Update the build and helm deployment files
1. Update the VERSION variable in the Makefile
1. Update Helm values
- `aws-ebs-csi-driver/values.yaml`
- `aws-ebs-csi-driver/Chart.yaml`
1. Update `deploy/kubernetes/overlays/stable/kustomization.yaml`
- ECR images are deployed via an AWS-internal process. Please don't update the ECR overlay.

### Send a release PR
### Send a release PR to the release branch
At this point you should have all changes required for the release commit. Verify the changes via `git diff` and send a new PR with the release commit against the release branch. Note that if it doesn't exist, you'll need someone with write privileges to create it for you.

## Tag the release

Once the PR is merged, pull the release branch locally and tag the release commit with the relase tag. You'll need push privileges for this step.

```
Expand All @@ -73,19 +68,37 @@ git push upstream v0.7.0
```

## Verify the release on GitHub

The new tag should trigger a new Github release. Verify that it has run by going to [Releases](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/releases). Then, click on the new version and verify all assets have been created:

- Source code (zip)
- Source code (tar.gz)

## Promote the new images on GCR

## Promote the new image on GCR
Promote the new images from the staging repo by sending a PR to the kubernetes/k8s.io repo. Here's an [example PR](https://github.com/kubernetes/k8s.io/pull/1606).

## Merge the release commit to the main branch
## Promote the new image on ECR
Follow the AWS-internal process.

## Verify the images are available
In GCR:
- `docker pull k8s.gcr.io/provider-aws/aws-ebs-csi-driver:v1.1.1`
In ECR:
- `aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 602401143452.dkr.ecr.us-west-2.amazonaws.com`
- `docker pull 602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/aws-ebs-csi-driver:v1.1.1`

## Create a post-release commit in the release branch

### Update the kustomize deployment files
1. Update the kustomize overlays
- `deploy/kubernetes/overlays/stable/kustomization.yaml`
- `deploy/kubernetes/overlays/stable/ecr/kustomization.yaml`

### Send a post-release PR to the release branch
The kustomize deployment files must not be updated to refer to the new images until after the images have been verified available, therefore it's necessary to make these changes in a post-release PR rather than the original release PR.

## Merge the release and post-release commits to the main branch

Once the images promoted, send a PR to merge the release commit to the main branch.
Send a PR to merge both the release and post-release commits to the main branch.

## Verify the helm chart release

Expand Down