github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-07-23 19:56:01 +00:00
Code Issues Projects Releases Wiki Activity

Update the section on jenkins changes for a new branch.

Browse Source 
This reflects the actual state of things at the moment.
There is quite a bit of assumed knowledge here in a rapidly changing
(test) environment.

referencing #22672.
This commit is contained in:
David McMahon 2016-03-08 18:21:08 -08:00
parent dba955e112
commit aedc7c4942
1 changed files with 25 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
docs/devel/releasing.md
View File

@ -226,23 +226,31 @@ been automated that need to happen after the branch has been cut:
the unversioned warning in docs point to the latest release series. Please
send the changes as a PR titled "Update the latestReleaseBranch to
release-X.Y in the munger".
1. Add test jobs for the new branch.
1. See [End-2-End Testing in Kubernetes](e2e-tests.md) for the test jobs
that should be running in CI, which are under version control in
`hack/jenkins/e2e.sh` (on the release branch) and
`hack/jenkins/job-configs/kubernetes-e2e.yaml` (in `master`). You'll
want to munge these for the release branch so that, as we cherry-pick
fixes onto the branch, we know that it builds, etc. (Talk with
@ihmccreery for more details.)
1. Make sure all features that are supposed to be GA are covered by tests,
but remove feature tests on the release branch for features that aren't
GA. You can use `hack/list-feature-tests.sh` to see a list of tests
labeled as `[Feature:.+]`; make sure that these are all either covered in
CI jobs on the release branch or are experimental features. (The answer
should already be 'yes', but this is a good time to reconcile.)
1. Make a dashboard in Jenkins that contains all of the jobs for this
release cycle, and also add them to Critical Builds. (Don't add them to
the merge-bot blockers; see kubernetes/contrib#156.)
1. Send a note to the test team (@kubernetes/goog-testing) that a new branch
has been created.
1. There is currently much work being done on our Jenkins infrastructure
and configs. Eventually we could have a relatively simple interface
to make this change or a way to automatically use the new branch.
See [recent Issue #22672](https://github.com/kubernetes/kubernetes/issues/22672).
1. You can provide this guidance in the email to aid in the setup:
1. See [End-2-End Testing in Kubernetes](e2e-tests.md) for the test jobs
that should be running in CI, which are under version control in
`hack/jenkins/e2e.sh` (on the release branch) and
`hack/jenkins/job-configs/kubernetes-jenkins/kubernetes-e2e.yaml`
(in `master`). You'll want to munge these for the release
branch so that, as we cherry-pick fixes onto the branch, we know that
it builds, etc. (Talk with @ihmccreery for more details.)
1. Make sure all features that are supposed to be GA are covered by tests,
but remove feature tests on the release branch for features that aren't
GA. You can use `hack/list-feature-tests.sh` to see a list of tests
labeled as `[Feature:.+]`; make sure that these are all either
covered in CI jobs on the release branch or are experimental
features. (The answer should already be 'yes', but this is a
good time to reconcile.)
1. Make a dashboard in Jenkins that contains all of the jobs for this
release cycle, and also add them to Critical Builds. (Don't add
them to the merge-bot blockers; see kubernetes/contrib#156.)
## Injecting Version into Binaries