@@ -59,8 +59,10 @@ The submit-queue does the following:
...
@@ -59,8 +59,10 @@ The submit-queue does the following:
```go
```go
for_,pr:=rangereadyToMergePRs(){
for_,pr:=rangereadyToMergePRs(){
iftestsAreStable(){
iftestsAreStable(){
ifretestPR(pr)==success{
mergePR(pr)
mergePR(pr)
}
}
}
}
}
```
```
...
@@ -68,92 +70,66 @@ The status of the submit-queue is [online.](http://submit-queue.k8s.io/)
...
@@ -68,92 +70,66 @@ The status of the submit-queue is [online.](http://submit-queue.k8s.io/)
### Ready to merge status
### Ready to merge status
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.
A PR is considered "ready for merging" if it matches the following:
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
* The PR must have the label "cla: yes" or "cla: human-approved"
* it has passed the cla pre-submit and has the `cla:yes` label
* The PR must be mergeable. aka cannot need a rebase
* it has passed the travis pre-submit tests
* All of the following github statuses must be green
* one (or all) of
* Jenkins GCE Node e2e
* its author is in kubernetes/contrib/submit-queue/whitelist.txt
* Jenkins GCE e2e
* its author is in contributors.txt via the github API.
* Jenkins unit/integration
* the PR has the `ok-to-merge` label
* The PR cannot have any prohibited future milestones (such as a v1.5 milestone during v1.4 code freeze)
* One (or both of)
* The PR must have the "lgtm" label
* it has passed the Jenkins e2e test
* The PR must not have been updated since the "lgtm" label was applied
* it has the `e2e-not-required` label
* The PR must not have the "do-not-merge" label
Note that the combined whitelist/committer list is available at
[submit-queue.k8s.io](http://submit-queue.k8s.io)
### 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).