diff --git a/release-tools/KUBERNETES_CSI_OWNERS_ALIASES b/release-tools/KUBERNETES_CSI_OWNERS_ALIASES index 8ea922ed..2f3e2dfc 100644 --- a/release-tools/KUBERNETES_CSI_OWNERS_ALIASES +++ b/release-tools/KUBERNETES_CSI_OWNERS_ALIASES @@ -31,15 +31,7 @@ aliases: # This documents who previously contributed to Kubernetes-CSI # as approver. -emeritus_approver: +emeritus_approvers: - lpabon - sbezverk - vladimirvivien - -# This documents who previously contributed to Kubernetes-CSI -# as reviewer. -emeritus_reviewer: -- lpabon -- saad-ali -- sbezverk -- vladimirvivien diff --git a/release-tools/SIDECAR_RELEASE_PROCESS.md b/release-tools/SIDECAR_RELEASE_PROCESS.md index e4b30e89..8977fbe6 100644 --- a/release-tools/SIDECAR_RELEASE_PROCESS.md +++ b/release-tools/SIDECAR_RELEASE_PROCESS.md @@ -46,10 +46,13 @@ naming convention `-on-`. ## Release Process 1. Identify all issues and ongoing PRs that should go into the release, and drive them to resolution. -1. Download v2.8+ [K8s release notes - generator](https://github.com/kubernetes/release/tree/HEAD/cmd/release-notes) +1. Download the latest version of the + [K8s release notes generator](https://github.com/kubernetes/release/tree/HEAD/cmd/release-notes) +1. Create a + [Github personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) + with `repo:public_repo` access 1. Generate release notes for the release. Replace arguments with the relevant - information. + information. * Clean up old cached information (also needed if you are generating release notes for multiple repos) ```bash @@ -57,15 +60,24 @@ naming convention `-on-`. ``` * For new minor releases on master: ```bash - GITHUB_TOKEN= release-notes --discover=mergebase-to-latest - --github-org=kubernetes-csi --github-repo=external-provisioner - --required-author="" --output out.md + GITHUB_TOKEN= release-notes \ + --discover=mergebase-to-latest \ + --org=kubernetes-csi \ + --repo=external-provisioner \ + --required-author="" \ + --markdown-links \ + --output out.md ``` * For new patch releases on a release branch: ```bash - GITHUB_TOKEN= release-notes --discover=patch-to-latest --branch=release-1.1 - --github-org=kubernetes-csi --github-repo=external-provisioner - --required-author="" --output out.md + GITHUB_TOKEN= release-notes \ + --discover=patch-to-latest \ + --branch=release-1.1 \ + --org=kubernetes-csi \ + --repo=external-provisioner \ + --required-author="" \ + --markdown-links \ + --output out.md ``` 1. Compare the generated output to the new commits for the release to check if any notable change missed a release note. @@ -100,6 +112,29 @@ naming convention `-on-`. and [k/k in-tree](https://github.com/kubernetes/kubernetes/tree/HEAD/test/e2e/testing-manifests/storage-csi/hostpath/hostpath) +### Troubleshooting + +#### Image build jobs + +The following jobs are triggered after tagging to produce the corresponding +image(s): +https://k8s-testgrid.appspot.com/sig-storage-image-build + +Clicking on a failed build job opens that job in https://prow.k8s.io. Next to +the job title is a rerun icon (circle with arrow). Clicking it opens a popup +with a "rerun" button that maintainers with enough permissions can use. If in +doubt, ask someone on #sig-release to rerun the job. + +Another way to rerun a job is to search for it in https://prow.k8s.io and click +the rerun icon in the resulting job list: +https://prow.k8s.io/?job=canary-csi-test-push-images + +#### Verify images + +Canary and staged images can be viewed at https://console.cloud.google.com/gcr/images/k8s-staging-sig-storage + +Promoted images can be viewed at https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/sig-storage + ## Adding support for a new Kubernetes release 1. Add the new release to `k8s_versions` in diff --git a/release-tools/prow.sh b/release-tools/prow.sh index 2cd1aea6..c08750fe 100755 --- a/release-tools/prow.sh +++ b/release-tools/prow.sh @@ -78,7 +78,7 @@ version_to_git () { # the list of windows versions was matched from: # - https://hub.docker.com/_/microsoft-windows-nanoserver # - https://hub.docker.com/_/microsoft-windows-servercore -configvar CSI_PROW_BUILD_PLATFORMS "linux amd64 amd64; linux ppc64le ppc64le -ppc64le; linux s390x s390x -s390x; linux arm arm -arm; linux arm64 arm64 -arm64; linux arm arm/v7 -armv7; windows amd64 amd64 .exe nanoserver:1809 servercore:ltsc2019; windows amd64 amd64 .exe nanoserver:1909 servercore:1909; windows amd64 amd64 .exe nanoserver:2004 servercore:2004; windows amd64 amd64 .exe nanoserver:20H2 servercore:20H2; windows amd64 amd64 .exe nanoserver:ltsc2022 servercore:ltsc2022" "Go target platforms (= GOOS + GOARCH) and file suffix of the resulting binaries" +configvar CSI_PROW_BUILD_PLATFORMS "linux amd64 amd64; linux ppc64le ppc64le -ppc64le; linux s390x s390x -s390x; linux arm arm -arm; linux arm64 arm64 -arm64; linux arm arm/v7 -armv7; windows amd64 amd64 .exe nanoserver:1809 servercore:ltsc2019; windows amd64 amd64 .exe nanoserver:20H2 servercore:20H2; windows amd64 amd64 .exe nanoserver:ltsc2022 servercore:ltsc2022" "Go target platforms (= GOOS + GOARCH) and file suffix of the resulting binaries" # If we have a vendor directory, then use it. We must be careful to only # use this for "make" invocations inside the project's repo itself because @@ -737,7 +737,7 @@ install_csi_driver () { fi } -# Installs all nessesary snapshotter CRDs +# Installs all necessary snapshotter CRDs install_snapshot_crds() { # Wait until volumesnapshot CRDs are in place. CRD_BASE_DIR="https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/${CSI_SNAPSHOTTER_VERSION}/client/config/crd"