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: release-engineering/handbooks/k8s-release-cut.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -153,14 +153,14 @@ krel version
153
153
Run the following command ([source](https://github.com/kubernetes-sigs/promo-tools/blob/main/docs/promotion-pull-requests.md#preparing-environment)) to get the latest release of `kpromo`:
154
154
155
155
```
156
-
go install sigs.k8s.io/promo-tools/v4/cmd/kpromo@latest
156
+
go install sigs.k8s.io/promo-tools/v4/cmd/kpromo@main
157
157
```
158
158
159
-
or to get the latest version directly from main:
159
+
or to build the latest version directly from a target branch:
@@ -526,7 +526,7 @@ krel history --branch release-1.33 --date-from 2025-04-23
526
526
> The new release branch is created in the `nomock` staging phase and pushed to the repository during the `nomock` release phase of an rc.0 cut.
527
527
528
528
During a `rc.0` release our release tooling creates a new release branch named `release-X.Y`, where `X.Y.0` is the version of the upcoming release.
529
-
For example: `release-1.18` also automatically triggers an alpha.0 build for the subsequent release [`v1.19.0-alpha.0`](https://github.com/kubernetes/kubernetes/releases/tag/v1.19.0-alpha.0).
529
+
Additionally, the `rc.0` release automatically triggers an `alpha.0` build for the subsequent release (e.g. for `v1.34.0-rc.0`, `v1.35.0-alpha.0` is created automatically).
530
530
531
531
Behind the scenes `krel` is executing a `git branch create` command and `git push`.
This document details the tasks that need to be executed after cutting a Kubernetes rc.0 release. These tasks ensure proper configuration for the new release branch and testing infrastructure.
25
-
They must be executed after the nomock release stage is completed, and the release branch is created, as stated in the [branch creation chapter](k8s-release-cut.md#next-release-branch-creation) of the release cut handbook.
24
+
They must be executed after the `nomock release` is completed, and the release branch is created, as stated in the [branch creation chapter](k8s-release-cut.md#next-release-branch-creation) of the release cut handbook.
26
25
27
26
PR can be created beforehand (and this is recommended in order to get reviews in a timely manner) but you got to remember to put a `/hold` on all the PRs, they have to be lifted only once the `nomock` release phase is done and the branch is created.
28
27
@@ -68,7 +67,6 @@ Only remove the oldest version if it is already EOL and the release branch jobs
68
67
# Edit this file: config/prow/plugins.yaml
69
68
70
69
# Add the new version and remove the oldest version in the kubernetes/kubernetes section - if the oldest version is EOL:
71
-
```yaml
72
70
milestone_applier:
73
71
kubernetes/kubernetes:
74
72
master: v1.33
@@ -83,7 +81,7 @@ Look out for the code freeze config and ensure excluded and included branches in
83
81
84
82
### Update Kubekins-e2e
85
83
86
-
Create a PR to update the kubekins-e2e `kubekins-e2e-v2/variants.yaml` file with the new version's configuration.
84
+
Create a PR to update the `kubekins-e2e-v2/variants.yaml` file with the new version's configuration.
87
85
File can be found [here](https://github.com/kubernetes/test-infra/blob/master/images/kubekins-e2e-v2/variants.yaml).
88
86
89
87
> [!WARNING]
@@ -122,18 +120,13 @@ First of all you need to modify the `releng/test_config.yaml` file ([here](https
122
120
> [!NOTE]
123
121
Just shift "args" but not touch interval, sigowners or any other field.
124
122
Remember that args are bound to a set of tests for a specific release, while intervals and everything else is bound to a release "status": stable1/2/3/4 or beta. An example of how to correctly rotate the jobs can be found [here](https://github.com/kubernetes/test-infra/pull/34668/commits/819c9d253ab873aff6626a5eaf7635560f7b769e).
125
-
Keep in mind that jobs order might be different, e.g. stable1 and stable2 jobs might not be the same job, so remember to pay particular attention where you're copying from and to.
126
-
127
-
The docs related to these steps are available in the [test-infra releng README](https://github.com/kubernetes/test-infra/blob/master/releng/README.md), they are to be used when you need to update the test configurations for the upcoming release branch and to generate the new Testgrid dashboards.
123
+
Keep in mind that jobs order might be different, e.g. the first stable1 job and and the first stable2 job might not be the same type of the job, so remember to pay particular attention where you're copying from and to.
128
124
129
-
Below is a more verbose breakdown of the steps.
125
+
Remember to update all configs before running the [generation script](#run-test-generation-script) for the upcoming release branch jobs.
130
126
131
127
#### Create the release dashboards
132
128
133
-
> [!WARNING]
134
-
Remember to updating all configs before running [this make command](https://github.com/kubernetes/test-infra/blob/master/releng/README.md#generate-jobs).
135
-
136
-
After running the `make` command you can now update the [release dashboards](https://github.com/kubernetes/test-infra/blob/master/config/testgrids/kubernetes/sig-release/config.yaml), example [commit](https://github.com/kubernetes/test-infra/commit/31fb8f2b5c4458af675e37765dfebd128da19971), remembering to:
129
+
After configuring the jobs you can now update the [release dashboards](https://github.com/kubernetes/test-infra/blob/master/config/testgrids/kubernetes/sig-release/config.yaml), example [commit](https://github.com/kubernetes/test-infra/commit/31fb8f2b5c4458af675e37765dfebd128da19971), remembering to:
137
130
138
131
- Remove the deprecated release sig-release-1.30-{blocking,informing} dashboards
139
132
- Add the new dashboards for the current release e.g., sig-release-1.34-{blocking,informing}
@@ -144,7 +137,7 @@ Comparing the new jobs with previous version(s) might help to identify any missi
144
137
145
138
#### Run test generation script
146
139
147
-
After updating the configurations you can run the following command from the root of your `test-infra` fork to generate the updated test configurations, remember to use the correct architecture and OS for your environment, e.g., `GOARCH=arm64 GOOS=darwin` for macOS on ARM:
140
+
After updating the configurations you can run the following command from the root of your `test-infra` fork to generate the updated jobs configurations, remember to use the correct architecture and OS for your environment, e.g., `GOARCH=arm64 GOOS=darwin` for macOS on ARM:
148
141
149
142
```bash
150
143
GOARCH=arm64 GOOS=darwin make -C releng prepare-release-branch
@@ -224,14 +217,12 @@ Before updating the builder images, you need to update the kube-cross image whic
224
217
Part of this work on k8s-cloud-builder and k8s-ci-builder could have been done as part of the Golang bumps, but it is worth mentioning here as it is a common step.
225
218
In any case you should always update the k8s-cloud-builder and k8s-ci-builder images to use the new kube-cross image.
226
219
227
-
#### Update k8s-cloud-builder and k8s-ci-builder images
228
-
229
-
Once the kube-cross image is available:
220
+
Once the updated kube-cross image is available:
230
221
231
222
1. Update the k8s-cloud-builder variants.yaml file:
0 commit comments