Document release process #768
Conversation
k8s-ci-robot
added
cncf-cla: yes
|
/assign @roberthbailey |
docs/developer/releasing.md
Outdated
|
|
||
| 1. Push a git tag | ||
| 2. Build and push the container image with `make docker-push`. Note: This | ||
| container registry has extremely limited access. You likely do not have |
There was a problem hiding this comment.
Can/should we link to documentation on who has authority?
There was a problem hiding this comment.
I'd guess @roberthbailey knows and can help provide additional context to this document
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chuckha, vincepri The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
docs/developer/releasing.md
Outdated
| # Process | ||
|
|
||
| 1. Push a git tag | ||
| 2. Build and push the container image with `make docker-push`. Note: This |
There was a problem hiding this comment.
You either need to set CONTROLLER_IMG before running the make command or edit the Makefile so that the pushed image has the correct tag.
There was a problem hiding this comment.
If we have to do a PR dance to cut a release (to embed version numbers) then it might make sense to have that include editing the version in the Makefile too).
docs/developer/releasing.md
Outdated
|
|
||
| # Process | ||
|
|
||
| 1. Push a git tag |
There was a problem hiding this comment.
Also need to set the image version in the generated yaml so that when the providers vendor the git tag their will start the correct container image.
See #635
k8s-ci-robot
added
size/M
|
@roberthbailey thank you for the feedback! I updated the pr, ptal |
|
|
||
| ## Process | ||
|
|
||
| 1. Create a pull request that contains two changes: |
There was a problem hiding this comment.
For Velero, we use goreleaser and have a custom script that executes at release time (after the git tag has been created) that uses sed to find/replace :latest with 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.
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.
| 1. Create a pull request that contains two changes: | ||
| 1. Change [the cluster api controller manager image | ||
| 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
| ## 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 Makefile target that can make these changes, and second target to undo them?
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 😄
|
@roberthbailey @chuckha what's left to get this merged? |
|
@ncdc I'm waiting for @roberthbailey's feedback. I've only written down what I can assume are the steps to releasing, he's the only one (?) that's done it and I'd like this document to reflect the real process. |
| 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 | ||
|
|
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.
|
|
||
| ### 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.
|
/milestone v1alpha1 |
Signed-off-by: Chuck Ha <[email protected]>
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/retest |
Signed-off-by: Chuck Ha [email protected]
What this PR does / why we need it:
This PR documents the release process for this repository. The eventual goal is to understand the pieces of release and come up with automated systems. There is potential for sharing this work
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #764
Related to #732
Special notes for your reviewer:
This is a best guess at how release works.
/cc @roberthbailey