|
| 1 | +# Sidecar Release Process |
| 2 | + |
| 3 | +This page describes the process for releasing a kubernetes-csi sidecar. |
| 4 | + |
| 5 | +## Prerequisites |
| 6 | + |
| 7 | +The release manager must: |
| 8 | + |
| 9 | +* Be a member of the kubernetes-csi organization. Open an |
| 10 | + [issue](https://github.com/kubernetes/org/issues/new?assignees=&labels=area%2Fgithub-membership&template=membership.md&title=REQUEST%3A+New+membership+for+%3Cyour-GH-handle%3E) in |
| 11 | + kubernetes/org to request membership |
| 12 | +* Be a top level approver for the repository. To become a top level approver, |
| 13 | + the candidate must demonstrate ownership and deep knowledge of the repository |
| 14 | + through active maintainence, responding to and fixing issues, reviewing PRs, |
| 15 | + test triage. |
| 16 | +* Be part of the maintainers or admin group for the repository. admin is a |
| 17 | + superset of maintainers, only maintainers level is required for cutting a |
| 18 | + release. Membership can be requested by submitting a PR to kubernetes/org. |
| 19 | + [Example](https://github.com/kubernetes/org/pull/1467) |
| 20 | + |
| 21 | +## Updating CI Jobs |
| 22 | +Whenever a new Kubernetes minor version is released, our kubernetes-csi CI jobs |
| 23 | +must be updated. |
| 24 | + |
| 25 | +[Our CI jobs](https://k8s-testgrid.appspot.com/sig-storage-csi-ci) have the |
| 26 | +naming convention `<hostpath-deployment-version>-on-<kubernetes-version>`. |
| 27 | + |
| 28 | +1. Jobs should be actively monitored to find and fix failures in sidecars and |
| 29 | + infrastructure changes early in the development cycle. Test failures are sent |
| 30 | + |
| 31 | +1. "-on-master" jobs are the closest reflection to the new Kubernetes version. |
| 32 | +1. Fixes to our prow.sh CI script can be tested in the [CSI hostpath |
| 33 | + repo](https://github.com/kubernetes-csi/csi-driver-host-path) by modifying |
| 34 | + [prow.sh](https://github.com/kubernetes-csi/csi-driver-host-path/blob/master/release-tools/prow.sh) |
| 35 | + along with any overrides in |
| 36 | + [.prow.sh](https://github.com/kubernetes-csi/csi-driver-host-path/blob/master/.prow.sh) |
| 37 | + to mirror the failing environment. Once e2e tests are passing (verify-unit tests |
| 38 | + will fail), then the prow.sh changes can be submitted to [csi-release-tools](https://github.com/kubernetes-csi/csi-release-tools). |
| 39 | +1. Changes can then be updated in all the sidecar repos and hostpath driver repo |
| 40 | + by following the [update |
| 41 | + instructions](https://github.com/kubernetes-csi/csi-release-tools/blob/master/README.md#sharing-and-updating). |
| 42 | +1. New pull and CI jobs are configured by |
| 43 | + [gen-jobs.sh](https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes-csi/gen-jobs.sh). |
| 44 | + New pull jobs that have been unverified should be initially made optional. |
| 45 | + [Example](https://github.com/kubernetes/test-infra/pull/15055) |
| 46 | +1. Once new pull and CI jobs have been verified, and the new Kubernetes version |
| 47 | + is released, we can make the optional jobs required, and also remove the |
| 48 | + Kubernetes versions that are no longer supported. |
| 49 | + |
| 50 | +## Release Process |
| 51 | +1. Identify all issues and ongoing PRs that should go into the release, and |
| 52 | + drive them to resolution. |
| 53 | +1. Download [K8s release notes |
| 54 | + generator](https://github.com/kubernetes/release/tree/master/cmd/release-notes) |
| 55 | +1. Generate release notes for the release. Replace arguments with the relevant |
| 56 | + information. |
| 57 | + ``` |
| 58 | + GITHUB_TOKEN=<token> ./release-notes --start-sha=0ed6978fd199e3ca10326b82b4b8b8e916211c9b --end-sha=3cb3d2f18ed8cb40371c6d8886edcabd1f27e7b9 \ |
| 59 | + --github-org=kubernetes-csi --github-repo=external-attacher -branch=master -output out.md |
| 60 | + ``` |
| 61 | + * `--start-sha` should point to the last release from the same branch. For |
| 62 | + example: |
| 63 | + * `1.X-1.0` tag when releasing `1.X.0` |
| 64 | + * `1.X.Y-1` tag when releasing `1.X.Y` |
| 65 | +1. Compare the generated output to the new commits for the release to check if |
| 66 | + any notable change missed a release note. |
| 67 | +1. Reword release notes as needed. Make sure to check notes for breaking |
| 68 | + changes and deprecations. |
| 69 | +1. If release is a new major/minor version, create a new `CHANGELOG-<major>.<minor>.md` |
| 70 | + file. Otherwise, add the release notes to the top of the existing CHANGELOG |
| 71 | + file for that minor version. |
| 72 | +1. Submit a PR for the CHANGELOG changes. |
| 73 | +1. Submit a PR for README changes, in particular, Compatibility, Feature status, |
| 74 | + and any other sections that may need updating. |
| 75 | +1. Check that all [canary CI |
| 76 | + jobs](https://k8s-testgrid.appspot.com/sig-storage-csi-ci) are passing, |
| 77 | + and that test coverage is adequate for the changes that are going into the release. |
| 78 | +1. Make sure that no new PRs have merged in the meantime, and no PRs are in |
| 79 | + flight and soon to be merged. |
| 80 | +1. Create a new release following a previous release as a template. Be sure to select the correct |
| 81 | + branch. This requires Github release permissions as required by the prerequisites. |
| 82 | + [external-provisioner example](https://github.com/kubernetes-csi/external-provisioner/releases/new) |
| 83 | +1. If release was a new major/minor version, create a new `release-<minor>` |
| 84 | + branch at that commit. |
| 85 | +1. Update [kubernetes-csi/docs](https://github.com/kubernetes-csi/docs) sidecar |
| 86 | + and feature pages with the new released version. |
| 87 | +1. After all the sidecars have been released, update |
| 88 | + CSI hostpath driver with the new sidecars in the [CSI repo](https://github.com/kubernetes-csi/csi-driver-host-path/tree/master/deploy) |
| 89 | + and [k/k |
| 90 | + in-tree](https://github.com/kubernetes/kubernetes/tree/master/test/e2e/testing-manifests/storage-csi/hostpath/hostpath) |
0 commit comments