🌱 Update RELEASE.md process for release branches #1228
Conversation
k8s-ci-robot
added
the
do-not-merge/hold
✅ Deploy Preview for kubernetes-sigs-cluster-api-openstack ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mdbooth 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
approved
| 1. Create an annotated tag | ||
| - `git tag -s -a $VERSION -m $VERSION`. | ||
| 1. Push the tag to the GitHub repository: | ||
| > NOTE: `upstream` should be the name of the remote pointing to `github.com/kubernetes-sigs/cluster-api-provider-openstack` | ||
| - `git push upstream $VERSION` | ||
| 1. Run `make release` to build artifacts (the image is automatically built by CI) |
There was a problem hiding this comment.
Shouldn't we recommend producing the artifacts and release notes while waiting for the image to build?
There was a problem hiding this comment.
This process is actually already doing that, although you've reminded me that I was confused about which step actually kicks off the build. I'm going document that the image build was kicked off automatically when we pushed the tag.
There was a problem hiding this comment.
Step 7 triggers the image build, while in step 8 we expect to have the image ready. We could do plenty of other things while the image is building. I was suggesting we move step 8 to a later stage, it could even be the last step before publishing the release IIUC.
Not really a big deal though as it doesn't take that long to build the image, and engineers will likely know when they can skip ahead.
There was a problem hiding this comment.
when I do previous releases I actually wait for the image ready and create promote then notify folks to review
and in the mean time do the other release stuff concurrently
mdbooth
force-pushed
the
release-docs
branch
2 times, most recently
from
2d75677 to
013482a
Compare
RELEASE.md
Outdated
| 1. Follow the [image promotion process](https://github.com/kubernetes/k8s.io/tree/main/k8s.gcr.io#image-promoter) to promote the image from the staging repo to `k8s.gcr.io/capi-openstack`. | ||
| The staging repository can be inspected at https://console.cloud.google.com/gcr/images/k8s-staging-capi-openstack/GLOBAL. Be | ||
| sure to choose the top level `capi-openstack-controller`, which will provide the multi-arch manifest, rather than one for a specific architecture. | ||
| The image build logs are available at [Cloud Build](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-capi-openstack). | ||
| Add the new sha=>tag mapping to the [images.yaml](https://github.com/kubernetes/k8s.io/edit/main/k8s.gcr.io/images/k8s-staging-capi-openstack/images.yaml) (use the sha of the image with the corresponding tag). The PR to update the [images.yaml](https://github.com/kubernetes/k8s.io/edit/main/k8s.gcr.io/images/k8s-staging-capi-openstack/images.yaml) must be approved in the [OWNERS](https://github.com/kubernetes/k8s.io/blob/main/k8s.gcr.io/images/k8s-staging-capi-openstack/OWNERS) file and merged. | ||
| 1. Create a draft release in GitHub based on the tag created above | ||
| 1. Run `make release` to build artifacts to be attached to the GitHub release. | ||
| 1. Generate and finalize the release notes and add them to the draft release: |
There was a problem hiding this comment.
Can't add the release notes to the draft release that is only created in the next step.
- 1. Generate and finalize the release notes and add them to the draft release:
+ 1. Generate and finalize the release notes and save them for the next step:
| - `beta` for a beta release | ||
| - `rc` for a release candidate | ||
| and an additional index starting at 0. This takes the form: `vX.Y.Z-[suffix].N`. e.g. the first release candidate prior | ||
| to version 1.2.3 would be called `v1.2.3-rc.0`. |
There was a problem hiding this comment.
+1, we don't use rc before as far as I can tell
There was a problem hiding this comment.
Probably only important when making a new release branch.
| 1. Create an annotated tag | ||
| - `git tag -s -a $VERSION -m $VERSION`. | ||
| 1. Push the tag to the GitHub repository: | ||
| > NOTE: `upstream` should be the name of the remote pointing to `github.com/kubernetes-sigs/cluster-api-provider-openstack` | ||
| - `git push upstream $VERSION` | ||
| 1. Run `make release` to build artifacts (the image is automatically built by CI) |
There was a problem hiding this comment.
when I do previous releases I actually wait for the image ready and create promote then notify folks to review
and in the mean time do the other release stuff concurrently
Co-authored-by: Julian Tölle <julian.toelle97@gmail.com>
|
@jichenjc I added a note about not needing to wait for image promotion. |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/lgtm |
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
Lessons learned from v0.6.0.
/hold