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

Merge pull request #27001 from eparis/e2e-not-required

Browse Source 
Automatic merge from submit-queue

update automation.md
This commit is contained in:
k8s-merge-robot 2016-06-07 16:44:29 -07:00
commit 021c83131d
1 changed files with 35 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

92
docs/devel/automation.md
View File

@ -59,101 +59,77 @@ The submit-queue does the following:
```go ```go
for _, pr := range readyToMergePRs() { for _, pr := range readyToMergePRs() {
if testsAreStable() { if testsAreStable() {
if retestPR(pr) == success {
mergePR(pr) mergePR(pr)
} }
} }
}
``` ```
The status of the submit-queue is [online.](http://submit-queue.k8s.io/) The status of the submit-queue is [online.](http://submit-queue.k8s.io/)
### Ready to merge status ### Ready to merge status
A PR is considered "ready for merging" if it matches the following: The submit-queue lists what it believes are required on the [merge requirements tab](http://submit-queue.k8s.io/#/info) of the info page. That may be more up to date.
* it has the `lgtm` label, and that `lgtm` is newer than the latest commit
* it has passed the cla pre-submit and has the `cla:yes` label
* it has passed the travis pre-submit tests
* one (or all) of
* its author is in kubernetes/contrib/submit-queue/whitelist.txt
* its author is in contributors.txt via the github API.
* the PR has the `ok-to-merge` label
* One (or both of)
* it has passed the Jenkins e2e test
* it has the `e2e-not-required` label
Note that the combined whitelist/committer list is available at A PR is considered "ready for merging" if it matches the following:
[submit-queue.k8s.io](http://submit-queue.k8s.io) * The PR must have the label "cla: yes" or "cla: human-approved"
* The PR must be mergeable. aka cannot need a rebase
* All of the following github statuses must be green
* Jenkins GCE Node e2e
* Jenkins GCE e2e
* Jenkins unit/integration
* The PR cannot have any prohibited future milestones (such as a v1.5 milestone during v1.4 code freeze)
* The PR must have the "lgtm" label
* The PR must not have been updated since the "lgtm" label was applied
* The PR must not have the "do-not-merge" label
### Merge process ### Merge process
Merges _only_ occur when the `critical builds` (Jenkins e2e for gce, gke, Merges _only_ occur when the [critical builds](http://submit-queue.k8s.io/#/e2e)
scalability, upgrade) are passing. We're open to including more builds here, let are passing. We're open to including more builds here, let us know...
us know...
Merges are serialized, so only a single PR is merged at a time, to ensure Merges are serialized, so only a single PR is merged at a time, to ensure
against races. against races.
If the PR has the `e2e-not-required` label, it is simply merged. If the PR does If the PR has the `retest-not-required` label, it is simply merged. If the PR does
not have this label, e2e tests are re-run, if these new tests pass, the PR is not have this label the e2e, unit/integration, and node tests are re-run. If these
merged. tests pass a second time, the PR will be merged as long as the `critical builds` are
green when this PR finishes retesting.
If e2e flakes or is currently buggy, the PR will not be merged, but it will be
re-run on the following pass.
## Github Munger ## Github Munger
We also run a [github "munger."] We run a [github "munger"](https://github.com/kubernetes/contrib/tree/master/mungegithub).
(https://github.com/kubernetes/contrib/tree/master/mungegithub)
This runs repeatedly over github pulls and issues and runs modular "mungers" This runs repeatedly over github pulls and issues and runs modular "mungers"
similar to "mungedocs." similar to "mungedocs." The mungers include the 'submit-queue' referenced above along
with numerous other functions. See the README in the link above.
Currently this runs:
* blunderbuss - Tries to automatically find an owner for a PR without an
owner, uses mapping file here:
https://github.com/kubernetes/contrib/blob/master/mungegithub/blunderbuss.yml
* needs-rebase - Adds `needs-rebase` to PRs that aren't currently mergeable,
and removes it from those that are.
* size - Adds `size/xs` - `size/xxl` labels to PRs
* ok-to-test - Adds the `ok-to-test` message to PRs that have an `lgtm` but
the e2e-builder would otherwise not test due to whitelist
* ping-ci - Attempts to ping the ci systems (Travis) if they are missing from
a PR.
* lgtm-after-commit - Removes the `lgtm` label from PRs where there are
commits that are newer than the `lgtm` label
In the works:
* issue-detector - machine learning for determining if an issue that has been
filed is a `support` issue, `bug` or `feature`
Please feel free to unleash your creativity on this tool, send us new mungers Please feel free to unleash your creativity on this tool, send us new mungers
that you think will help support the Kubernetes development process. that you think will help support the Kubernetes development process.
## PR builder ## PR builder
We also run a robotic PR builder that attempts to run e2e tests for each PR. We also run a robotic PR builder that attempts to run tests for each PR.
Before a PR from an unknown user is run, the PR builder bot (`k8s-bot`) asks to Before a PR from an unknown user is run, the PR builder bot (`k8s-bot`) asks to
a message from a contributor that a PR is "ok to test", the contributor replies a message from a contributor that a PR is "ok to test", the contributor replies
with that message. Contributors can also add users to the whitelist by replying with that message. ("please" is optional, but remember to treat your robots with
with the message "add to whitelist" ("please" is optional, but remember to treat kindness...)
your robots with kindness...)
If a PR is approved for testing, and tests either haven't run, or need to be
re-run, you can ask the PR builder to re-run the tests. To do this, reply to the
PR with a message that begins with `@k8s-bot test this`, this should trigger a
re-build/re-test.
## FAQ: ## FAQ:
#### How can I ask my PR to be tested again for Jenkins failures? #### How can I ask my PR to be tested again for Jenkins failures?
Right now you have to ask a contributor (this may be you!) to re-run the test PRs should only need to be manually re-tested if you believe there was a flake
with "@k8s-bot test this" during the original test. All flakes should be filed as an
[issue](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Fflake).
Once you find or file a flake a contributer (this may be you!) should request
a retest with "@k8s-bot test this issue: #NNNNN", where NNNNN is replaced with
the issue number you found or filed.
### How can I kick Travis to re-test on a failure? Any pushes of new code to the PR will automatically trigger a new test. No human
interraction is required.
Right now the easiest way is to close and then immediately re-open the PR.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/devel/automation.md?pixel)]() [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/devel/automation.md?pixel)]()