Document release process #768
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,44 @@ | ||
| # Releasing | ||
|
|
||
| ## Output | ||
|
|
||
| ### Expected artifacts | ||
|
|
||
| 1. A container image of the shared cluster-api controller manager | ||
| 2. A git tag for providers to use | ||
|
|
||
| ### Artifact locations | ||
|
|
||
| 1. The container image is found in the registry `gcr.io/k8s-cluster-api` with an | ||
| image name of `cluster-api-controller` and a tag that matches the release | ||
| version. For example, in the `0.0.0-alpha.4` release, the container image | ||
| location is `gcr.io/k8s-cluster-api/cluster-api-controller:0.0.0-alpha.4` | ||
|
|
||
| ## Process | ||
|
|
||
| 1. Create a pull request that contains two changes: | ||
| 1. Change [the cluster api controller manager image | ||
|
There was a problem hiding this comment. Could we get a There was a problem hiding this comment. I agree, this PR dance is by far the most onerous part of the release process. There was a problem hiding this comment. It reminds me of Maven releases 😄 |
||
| tag][managerimg] from `:latest` to whatever version is being released | ||
| 2. Change the `CONTROLLER_IMAGE` variable in the [Makefile][makefile] to the | ||
|
There was a problem hiding this comment. Yep, that's the variable name |
||
| version being released | ||
| 2. Get the pull request merged | ||
| 3. From the commit in step 1 (that is now in the master branch), build and push | ||
| the container image with `make docker-push` | ||
| 4. Create a tag from this same commit and push the tag to the github repository | ||
| 5. Revert the commit made in step 1 | ||
| 6. Open a pull request with the revert change | ||
| 7. Get that pull request merged | ||
| 8. Create a release in github based on the tag created above | ||
| 9. Manually create the release notes by going through the merged PRs since the | ||
| last release | ||
|
|
||
|
There was a problem hiding this comment. Step 9 is to write release notes. Right now this is also a very manual process. For https://github.com/kubernetes-sigs/cluster-api/releases/tag/0.0.0-alpha.3 I basically went through all of the PRs that had merged since the prior release and manually curated the release notes. It's onerous, but the script in the k/k repo that does it didn't seem like it would work out of the box even though we use the same release notes block in our PRs. As you can tell, when I cut https://github.com/kubernetes-sigs/cluster-api/releases/tag/0.0.0-alpha.4 during kubecon I didn't have the time to make similarly thorough release notes. I've filed #327 to track building better automation for release note generation. |
||
| [managerimg]: https://github.com/kubernetes-sigs/cluster-api/blob/fab4c07ea9fb0f124a5abe3dd7fcfffc23f2a1b3/config/default/manager_image_patch.yaml | ||
| [makefile]: https://github.com/kubernetes-sigs/cluster-api/blob/fab4c07ea9fb0f124a5abe3dd7fcfffc23f2a1b3/Makefile | ||
|
|
||
| ### Permissions | ||
|
|
||
| Releasing requires a particular set of permissions. | ||
|
There was a problem hiding this comment. It sounds like this will change soon with the community owns staging buckets and the image promoter automation that is being built. But for now, this is how it's done. |
||
|
|
||
| * push access to the gcr bucket | ||
| * tag push access to the github repository | ||
| * release creation | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For Velero, we use
goreleaserand have a custom script that executes at release time (after the git tag has been created) that usessedto find/replace:latestwith the appropriate version string to match the git tag. That way, we don't have to open a PR, cut the release, then revert the PR. Would you be interested in exploring something like this down the road?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think anything that reduces the number of steps involved with releasing should be considered. I'll add a note in the Cluster API Provider Releases doc about goreleaser.