Skip to content

Commit af671f0

Browse files
authored
Merge pull request #255 from pohly/prow-update-master
master: update release-tools
2 parents ec9dda7 + a7d5780 commit af671f0

File tree

4 files changed

+292
-88
lines changed

4 files changed

+292
-88
lines changed

release-tools/README.md

Lines changed: 16 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -81,7 +81,7 @@ on what is enabled in Prow, see
8181
https://github.com/kubernetes/test-infra/tree/master/config/jobs/kubernetes-csi
8282

8383
Test results for periodic jobs are visible in
84-
https://testgrid.k8s.io/sig-storage-csi
84+
https://testgrid.k8s.io/sig-storage-csi-ci
8585

8686
It is possible to reproduce the Prow testing locally on a suitable machine:
8787
- Linux host
@@ -141,17 +141,6 @@ The `vendor` directory is optional. It is still present in projects
141141
because it avoids downloading sources during CI builds. If this is no
142142
longer deemed necessary, then a project can also remove the directory.
143143

144-
When using packages that are part of the Kubernetes source code, the
145-
commands above are not enough because the [lack of semantic
146-
versioning](https://github.com/kubernetes/kubernetes/issues/72638)
147-
prevents `go mod` from finding newer releases. Importing directly from
148-
`kubernetes/kubernetes` also needs `replace` statements to override
149-
the fake `v0.0.0` versions
150-
(https://github.com/kubernetes/kubernetes/issues/79384). The
151-
`go-get-kubernetes.sh` script can be used to update all packages in
152-
lockstep to a different Kubernetes version. It takes a single version
153-
number like "1.16.0".
154-
155144
Conversion of a repository that uses `dep` to `go mod` can be done with:
156145

157146
GO111MODULE=on go mod init
@@ -160,3 +149,18 @@ Conversion of a repository that uses `dep` to `go mod` can be done with:
160149
GO111MODULE=on go mod vendor
161150
git rm -f Gopkg.toml Gopkg.lock
162151
git add go.mod go.sum vendor
152+
153+
### Updating Kubernetes dependencies
154+
155+
When using packages that are part of the Kubernetes source code, the
156+
commands above are not enough because the [lack of semantic
157+
versioning](https://github.com/kubernetes/kubernetes/issues/72638)
158+
prevents `go mod` from finding newer releases. Importing directly from
159+
`kubernetes/kubernetes` also needs `replace` statements to override
160+
the fake `v0.0.0` versions
161+
(https://github.com/kubernetes/kubernetes/issues/79384). The
162+
`go-get-kubernetes.sh` script can be used to update all packages in
163+
lockstep to a different Kubernetes version. Example usage:
164+
```
165+
$ ./release-tools/go-get-kubernetes.sh 1.16.4
166+
```
Lines changed: 90 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,90 @@
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)

release-tools/build.make

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -70,6 +70,7 @@ build-%: check-go-version-go
7070
CGO_ENABLED=0 GOOS=linux go build $(GOFLAGS_VENDOR) -a -ldflags '-X main.version=$(REV) -extldflags "-static"' -o ./bin/$* ./cmd/$*
7171
if [ "$$ARCH" = "amd64" ]; then \
7272
CGO_ENABLED=0 GOOS=windows go build $(GOFLAGS_VENDOR) -a -ldflags '-X main.version=$(REV) -extldflags "-static"' -o ./bin/$*.exe ./cmd/$* ; \
73+
CGO_ENABLED=0 GOOS=linux GOARCH=ppc64le go build $(GOFLAGS_VENDOR) -a -ldflags '-X main.version=$(REV) -extldflags "-static"' -o ./bin/$*-ppc64le ./cmd/$* ; \
7374
fi
7475

7576
container-%: build-%
@@ -112,7 +113,7 @@ test-go:
112113
test: test-vet
113114
test-vet:
114115
@ echo; echo "### $@:"
115-
go test $(GOFLAGS_VENDOR) `go list $(GOFLAGS_VENDOR) ./... | grep -v vendor $(TEST_VET_FILTER_CMD)`
116+
go vet $(GOFLAGS_VENDOR) `go list $(GOFLAGS_VENDOR) ./... | grep -v vendor $(TEST_VET_FILTER_CMD)`
116117

117118
.PHONY: test-fmt
118119
test: test-fmt

0 commit comments

Comments
 (0)