You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/ISSUE_TEMPLATE/new_release.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,12 +14,12 @@ For details, see [RELEASE.md](https://github.com/kubernetes-sigs/cluster-api-pro
14
14
-[ ][When bumping `X` or `Y`] Add a new entry of new release branch to [depandabot.yml](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/.github/dependabot.yml).
15
15
-[ ][When bumping `X` or `Y`] Add a new entry of new release branch to [security-scan.yaml](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/.github/workflows/security-scan.yaml).
16
16
-[ ][When bumping `X` or `Y`] Add a new entry to [metadata.yaml](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/metadata.yaml)
17
-
as [described in the CAPI book](https://cluster-api.sigs.k8s.io/clusterctl/provider-contract.html#metadata-yaml)
17
+
as [described in the CAPI book](https://cluster-api.sigs.k8s.io/developer/providers/contracts/clusterctl#metadata-yaml)
18
18
on the release branch prior to release.
19
-
-[ ]Push tag to the repository.
19
+
-[ ]Create the PR after generating release notes according to [RELEASE.md](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/RELEASE.md). Verify that the release PR looks good and make changes if necessary. When this PR is merged, release automation will push the tag to upstream and create a draft release notes.
20
20
-[ ] Promote the [staging image](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-capi-openstack) by
21
21
adding the new sha=>tag mapping to [images.yaml](https://github.com/kubernetes/k8s.io/blob/main/registry.k8s.io/images/k8s-staging-capi-openstack/images.yaml).
22
-
-[ ] Verify that the new draft release looks good and make changes if necessary.
22
+
-[ ] Verify that the new draft release looks good.
23
23
-[ ] Verify that the image was promoted sucessfully.
24
24
-[ ] Publish the release.
25
25
Mark the release as "latest" if it is the most recent minor release.
Copy file name to clipboardExpand all lines: RELEASE.md
+57-24Lines changed: 57 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,40 +41,73 @@ The content of the release notes differs depending on the type of release, speci
41
41
There is an [issue template](.github/ISSUE_TEMPLATE/new_release.md) to help track release activities.
42
42
43
43
1. Make sure your repo is clean by git's standards. It is recommended to use a fresh checkout.
44
-
1. When bumping `X` or `Y` (but not Z or the pre-release suffix) in the release version you must create a new release branch called `release-X.Y`.
45
-
> NOTE: `upstream` should be the name of the remote pointing to `github.com/kubernetes-sigs/cluster-api-provider-openstack`
46
-
-`git checkout main`
47
-
-`git pull`
48
-
-`git checkout -b release-X.Y`
49
-
-`git push --set-upstream upstream`
44
+
1. Repository Setup
45
+
- Clone the repository: `git clone [email protected]:kubernetes-sigs/cluster-api-provider-openstack.git`
46
+
or if using existing repository, make sure origin is set to the fork and
47
+
upstream is set to `kubernetes-sigs`. Verify if your remote is set properly or not
48
+
by using following command `git remote -v`.
49
+
- Fetch the remote (`kubernetes-sigs`): `git fetch upstream`
50
+
This makes sure that all the tags are accessible.
51
+
50
52
1. When bumping `X` or `Y` (but not Z or the pre-release suffix) in the release version, ensure you have added a new
51
53
entry to [metadata.yaml](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/metadata.yaml)
52
-
as [described in the CAPI book](https://cluster-api.sigs.k8s.io/clusterctl/provider-contract.html#metadata-yaml), and
54
+
as [described in the CAPI book](https://cluster-api.sigs.k8s.io/developer/providers/contracts/clusterctl#metadata-yaml), and
53
55
that this has been committed to the release branch prior to release.
54
-
1. Make sure you are on the correct release branch: `release-X.Y`
55
-
1. Set an environment variable with the version, e.g.:
56
-
-`VERSION=v0.6.0`
57
-
1. Create an annotated tag
58
-
-`git tag -s -a $VERSION -m $VERSION`.
59
-
1. Push the tag to the GitHub repository:
60
-
> NOTE: `upstream` should be the name of the remote pointing to `github.com/kubernetes-sigs/cluster-api-provider-openstack`
61
-
-`git push upstream $VERSION`
62
-
63
-
This will cause the image to be automatically built by CI and pushed to the staging repository. As this only builds
64
-
the image, it only takes a few minutes.
65
-
It also triggers the [release](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/.github/workflows/release.yaml) workflow which will generate release notes and artifacts, and create a draft release in GitHub.
66
-
1. Follow the [image promotion process](https://github.com/kubernetes/k8s.io/blob/main/registry.k8s.io/README.md#image-promoter) to promote the image from the staging repo to `registry.k8s.io/capi-openstack`.
67
-
The staging repository can be inspected at https://console.cloud.google.com/gcr/images/k8s-staging-capi-openstack/GLOBAL. Be
56
+
57
+
1. Creating Release Notes
58
+
- Switch to the main branch: `git checkout main`
59
+
- Create a new branch for the release notes**:
60
+
`git checkout -b release-notes-X.Y.Z origin/main`
61
+
- Generate the release notes: `RELEASE_TAG=vX.Y.Z make generate-release-notes`
62
+
- Replace `vX.Y.Z` with the new release tag you're creating.
63
+
- This command generates the release notes here
64
+
`releasenotes/<RELEASE_TAG>.md` .
65
+
66
+
1. Next step is to clean up the release note manually.
67
+
- If release is not an alpha or a beta or release candidate, check for duplicates,
68
+
reverts, and incorrect classifications of PRs, and whatever release
69
+
creation tagged to be manually checked.
70
+
- For any superseded PRs (like same dependency uplifted multiple times, or
71
+
commit revertion) that provide no value to the release, move them to
72
+
Superseded section. This way the changes are acknowledged to be part of the
73
+
release, but not overwhelming the important changes contained in the release.
74
+
- Commit your changes, push the new branch and create a pull request:
75
+
- The commit and PR title should be 🚀 Release v1.x.y:
76
+
-`git commit -S -s -m ":rocket: Release vX.Y.Z"`
77
+
-`git push -u origin release-notes-X.Y.Z`
78
+
- Important! The commit should only contain the release notes file, nothing
79
+
else, otherwise automation will not work.
80
+
- Ask maintainers and release team members to review your pull request.
81
+
82
+
Once PR is merged following GitHub actions are triggered:
83
+
84
+
- GitHub action `Create Release` runs following jobs
85
+
- GitHub job `push_release_tags` will create and push the tags. This action
86
+
will also create release branch if its missing and release is `rc` or minor.
This will cause the image to be automatically built by CI and pushed to the staging repository. As this only builds the image, it only takes a few minutes.
94
+
95
+
1. Follow the [image promotion process](https://github.com/kubernetes/k8s.io/blob/main/registry.k8s.io/README.md#image-promoter) to promote the image from the staging repo to `registry.k8s.io/capi-openstack`.
96
+
The staging repository can be inspected at [Staging CAPI Openstack](https://console.cloud.google.com/gcr/images/k8s-staging-capi-openstack/GLOBAL). Be
68
97
sure to choose the top level `capi-openstack-controller`, which will provide the multi-arch manifest, rather than one for a specific architecture.
69
98
The image build logs are available at [Cloud Build](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-capi-openstack).
70
99
Add the new sha=>tag mapping to the [images.yaml](https://github.com/kubernetes/k8s.io/blob/main/registry.k8s.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/blob/main/registry.k8s.io/images/k8s-staging-capi-openstack/images.yaml) must be approved in the [OWNERS](https://github.com/kubernetes/k8s.io/blob/main/registry.k8s.io/images/k8s-staging-capi-openstack/OWNERS) file and merged.
71
100
72
-
It is good practise to get somebody else to review this PR. It is safe to perform the following steps while waiting
73
-
for review and the promotion of the image.
101
+
It is good practise to get somebody else to review this PR. It is safe to perform the following steps while waiting for review and the promotion of the image.
102
+
74
103
1. Check carefully the [draft release](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/releases)
75
104
created by the workflow. Ensure that the release notes are correct and that the artifacts are present.
76
105
If any changes are needed, edit the release notes in the GitHub UI and add any missing artifacts.
77
106
1. Ensure that the release image has been promoted.
107
+
1. If the release you're making is not a new major release, new minor release,
108
+
or a new patch release from the latest release branch, uncheck the box for
109
+
latest release. If it is a release candidate (RC) or a beta or an alpha
110
+
release, tick pre-release box.
78
111
1. Publish release.
79
112
80
113
### Post release actions
@@ -96,5 +129,5 @@ Releasing requires a particular set of permissions.
96
129
97
130
There is a post-submit Prow job running after each commit on `main` which pushes a new image to the staging repo (`gcr.io/k8s-staging-capi-openstack/capi-openstack-controller:latest`). Following configuration is involved:
* post-submit `post-capi-openstack-push-images` Prow job: [kubernetes/test-infra/blob/master/config/jobs/image-pushing/k8s-staging-cluster-api.yaml](https://github.com/kubernetes/test-infra/blob/master/config/jobs/image-pushing/k8s-staging-cluster-api.yaml)) (corresponding dashboard is located at [https://testgrid.k8s.io/sig-cluster-lifecycle-image-pushes#post-capi-openstack-push-images](https://testgrid.k8s.io/sig-cluster-lifecycle-image-pushes#post-capi-openstack-push-images))
132
+
* post-submit `post-capi-openstack-push-images` Prow job: [kubernetes/test-infra/blob/master/config/jobs/image-pushing/k8s-staging-cluster-api.yaml](https://github.com/kubernetes/test-infra/blob/master/config/jobs/image-pushing/k8s-staging-cluster-api.yaml) (corresponding dashboard is located at [https://testgrid.k8s.io/sig-cluster-lifecycle-image-pushes#post-capi-openstack-push-images](https://testgrid.k8s.io/sig-cluster-lifecycle-image-pushes#post-capi-openstack-push-images))
100
133
* Google Cloud Build configuration which is used by the Prow job: [kubernetes-sigs/cluster-api-provider-openstack/cloudbuild.yaml](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/cloudbuild.yaml)
0 commit comments