# Kubernetes Development Automation

## Overview

Kubernetes uses a variety of automated tools in an attempt to relieve developers
of repetitive, low brain power work. This document attempts to describe these
processes.


## Submit Queue

In an effort to
   * reduce load on core developers
   * maintain end-to-end test stability
   * load test github's label feature

We have added an automated [submit-queue](https://git.k8s.io/test-infra/mungegithub/submit-queue)
to the
[github "munger"](https://git.k8s.io/test-infra/mungegithub)
for kubernetes.

The submit-queue does the following:

```go
for _, pr := range readyToMergePRs() {
    if testsAreStable() {
        if retestPR(pr) == success {
            mergePR(pr)
        }
    }
}
```

The status of the submit-queue is [online.](http://submit-queue.k8s.io/)

### Ready to merge status

A PR is considered "ready for merging" by the submit queue if it matches the set
of conditions listed in the [merge requirements tab](http://submit-queue.k8s.io/#/info)
of the info page.
Please visit that page for more details.

### Merge process

If the PR has the `retest-not-required` label, it is simply merged. If the PR does
not have this label, the aforementioned required tests are re-run.
If these tests pass a second time, the PR will be merged when this PR finishes retesting.

## Github Munger

We run [github "mungers"](https://git.k8s.io/test-infra/mungegithub).

This runs repeatedly over github pulls and issues and runs modular "mungers".
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.

### Closing stale pull-requests

Github Munger will close pull-requests that don't have human activity in the
last 90 days. It will warn about this process 60 days before closing the
pull-request, and warn again 30 days later. One way to prevent this from
happening is to add the `keep-open` label on the pull-request.

Feel free to re-open and maybe add the `keep-open` label if this happens to a
valid pull-request. It may also be a good opportunity to get more attention by
verifying that it is properly assigned and/or mention people that might be
interested. Commenting on the pull-request will also keep it open for another 90
days.

## PR builder

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-ci-robot`) asks to
a message from a kubernetes member that a PR is safe to test, the member can
reply with the `/ok-to-test` command on a single line to begin CI testing.

## FAQ:

#### How can I ask my PR to be tested again for Jenkins failures?

PRs should only need to be manually re-tested if you believe there was a flake
during the original test. It would be good to file flakes as an
[issue](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Fflake). 
`@k8s-ci-robot` will comment to tell you which test(s) failed and how to re-test. 
The simplest way is to comment `/retest`.

Any pushes of new code to the PR will automatically trigger a new test. No human
interraction is required. Note that if the PR has a `lgtm` label, it will be removed after the pushes.