mirror of https://github.com/k3s-io/k3s
Merge pull request #27001 from eparis/e2e-not-required
Automatic merge from submit-queue update automation.mdpull/6/head
k8s-merge-robot
commit
021c83131d
|
|
@ -59,7 +59,9 @@ The submit-queue does the following:
|
|||
```go
|
||||
for _, pr := range readyToMergePRs() {
|
||||
if testsAreStable() {
|
||||
mergePR(pr)
|
||||
if retestPR(pr) == success {
|
||||
mergePR(pr)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
@ -68,92 +70,66 @@ The status of the submit-queue is [online.](http://submit-queue.k8s.io/)
|
|||
|
||||
### Ready to merge status
|
||||
|
||||
A PR is considered "ready for merging" if it matches the following:
|
||||
* 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
|
||||
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.
|
||||
|
||||
Note that the combined whitelist/committer list is available at
|
||||
[submit-queue.k8s.io](http://submit-queue.k8s.io)
|
||||
A PR is considered "ready for merging" if it matches the following:
|
||||
* 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
|
||||
|
||||
Merges _only_ occur when the `critical builds` (Jenkins e2e for gce, gke,
|
||||
scalability, upgrade) are passing. We're open to including more builds here, let
|
||||
us know...
|
||||
Merges _only_ occur when the [critical builds](http://submit-queue.k8s.io/#/e2e)
|
||||
are passing. We're open to including more builds here, let us know...
|
||||
|
||||
Merges are serialized, so only a single PR is merged at a time, to ensure
|
||||
against races.
|
||||
|
||||
If the PR has the `e2e-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
|
||||
merged.
|
||||
|
||||
If e2e flakes or is currently buggy, the PR will not be merged, but it will be
|
||||
re-run on the following pass.
|
||||
If the PR has the `retest-not-required` label, it is simply merged. If the PR does
|
||||
not have this label the e2e, unit/integration, and node tests are re-run. If these
|
||||
tests pass a second time, the PR will be merged as long as the `critical builds` are
|
||||
green when this PR finishes retesting.
|
||||
|
||||
## Github Munger
|
||||
|
||||
We also run a [github "munger."]
|
||||
(https://github.com/kubernetes/contrib/tree/master/mungegithub)
|
||||
We run a [github "munger"](https://github.com/kubernetes/contrib/tree/master/mungegithub).
|
||||
|
||||
This runs repeatedly over github pulls and issues and runs modular "mungers"
|
||||
similar to "mungedocs."
|
||||
|
||||
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`
|
||||
similar to "mungedocs." The mungers include the 'submit-queue' referenced above along
|
||||
with numerous other functions. See the README in the link above.
|
||||
|
||||
Please feel free to unleash your creativity on this tool, send us new mungers
|
||||
that you think will help support the Kubernetes development process.
|
||||
|
||||
## 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
|
||||
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 the message "add to whitelist" ("please" is optional, but remember to treat
|
||||
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.
|
||||
|
||||
with that message. ("please" is optional, but remember to treat your robots with
|
||||
kindness...)
|
||||
|
||||
## FAQ:
|
||||
|
||||
#### 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
|
||||
with "@k8s-bot test this"
|
||||
PRs should only need to be manually re-tested if you believe there was a flake
|
||||
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?
|
||||
|
||||
Right now the easiest way is to close and then immediately re-open the PR.
|
||||
Any pushes of new code to the PR will automatically trigger a new test. No human
|
||||
interraction is required.
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
|
|
|
|||
Loading…
Reference in New Issue