kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update Development Automation and Pull Request Process

This commit is contained in:
xiangpengzhao 2017-09-04 12:11:39 +08:00
parent 0d25e180f3
commit 629d174403
2 changed files with 43 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
contributors/devel/automation.md
View File

@ -38,37 +38,31 @@ The status of the submit-queue is [online.](http://submit-queue.k8s.io/)
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:
* 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 must have the label `cncf-cla: yes` or `cla: human-approved`
* The PR must be mergeable, aka cannot need a rebase
* All of the required github CI tests must be green. The current list of tests are on the [MERGE REQUIREMENTS tab, at this link](https://submit-queue.k8s.io/#/info)
* 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 "lgtm" label is automatically applied
following a review comment consisting of only "LGTM" (case-insensitive)
* The PR must not have been updated since the "lgtm" label was applied
* The PR must not have the "do-not-merge" label
* The PR must have the `lgtm` label. The `lgtm` label is automatically applied
following a review comment consisting of `/lgtm` (case-insensitive) in a single line
* The PR must not have been updated since the `lgtm` label was applied
* The PR must have the `approved` label. The `approved` label is automatically
applied after all approvers have approved the PR by a comment consisting of
`/approve` (case-insensitive) in a single line
* The PR must not have the `do-not-merge` label or any of other `do-not-merge/*`
labels, e.g., `do-not-merge/release-note-label-needed`
### Merge process
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 `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.
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://github.com/kubernetes/contrib/tree/master/mungegithub).
We run [github "mungers"](https://github.com/kubernetes/test-infra/tree/master/mungegithub).
This runs repeatedly over github pulls and issues and runs modular "mungers"
similar to "mungedocs." The mungers include the 'submit-queue' referenced above along
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
@ -79,9 +73,9 @@ that you think will help support the Kubernetes development process.
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.
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
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
@ -91,24 +85,22 @@ days.
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. ("please" is optional, but remember to treat your robots with
kindness...)
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. 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 contributor (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.
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.
interraction is required. Note that if the PR has a `lgtm` label, it will be removed after the pushes.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/devel/automation.md?pixel)]()

30
contributors/devel/pull-requests.md
View File

@ -47,7 +47,8 @@ pass or fail of continuous integration.
You must sign the CLA before your first contribution. [Read more about the CLA.](https://github.com/kubernetes/community/blob/master/CLA.md)
If you haven't signed the Contributor License Agreement (CLA) before making a PR, the `k8s-ci-robot` will leave a comment with instructions on how to sign the CLA.
If you haven't signed the Contributor License Agreement (CLA) before making a PR,
the `@k8s-ci-robot` will leave a comment with instructions on how to sign the CLA.
# The PR Submit Process
@ -59,7 +60,7 @@ Merging a PR requires the following steps to be completed before the PR will be
- Add notes in the release notes block, or
- Update the release note label
- Pass all e2e tests
- Get a `LGTM` from a reviewer
- Get a `/lgtm` from a reviewer
- Get approval from an owner
If your PR meets all of the steps above, it will enter the submit queue to be merged. When it is next in line to be merged, the e2e tests will run a second time. If all tests pass, the PR will be merged automatically.
@ -99,38 +100,41 @@ Now that your release notes are in shape, let's look at how the PR gets tested a
## The Testing and Merge Workflow
The Kubernetes merge workflow uses comments to run tests and labels for merging PRs. NOTE: For pull requests that are in progress but not ready for review, prefix the PR title with "WIP" and track any remaining TODOs in a checklist in the pull request description.
The Kubernetes merge workflow uses comments to run tests and labels for merging PRs.
NOTE: For pull requests that are in progress but not ready for review,
prefix the PR title with `WIP` or `[WIP]` and track any remaining TODOs
in a checklist in the pull request description.
Here's the process the PR goes through on its way from submission to merging:
1. Make the pull request
1. mergebot assigns reviewers
1. `@k8s-merge-robot` assigns reviewers
If you're **not** a member of the Kubernetes organization:
1. Reviewer/Kubernetes Member checks that the PR is safe to test. If so, they comment `@k8s-bot ok to test`
1. Reviewer/Kubernetes Member checks that the PR is safe to test. If so, they comment `/ok-to-test`
1. Reviewer suggests edits
1. Push edits to your PR branch
1. Repeat the prior two steps as needed
1. (Optional) Some reviewers prefer that you squash commits at this step
1. Owner is assigned and will add the `/approve` label to the PR
If you are a member, or a member comments `@k8s-bot ok to test`, the pre-submit tests will run:
If you are a member, or a member comments `/ok-to-test`, the PR will be considered to be trusted. Then the pre-submit tests will run:
1. Automatic tests run. See the current list of tests on the [MERGE REQUIREMENTS tab, at this link](https://submit-queue.k8s.io/#/info)
1. If tests fail, resolve issues by pushing edits to your PR branch
1. If the failure is a flake, a member can comment `@k8s-bot [e2e|unit] test this issue: #<flake issue>`
1. If the failure is a flake, anyone on trusted PRs can comment `/retest` to rerun failed tests
Once the tests pass, all failures are commented as flakes, or the reviewer adds the labels `lgtm` and `approved`, the PR enters the final merge queue. The merge queue is needed to make sure no incompatible changes have been introduced by other PRs since the tests were last run on your PR.
Either the [on call contributor](on-call-rotations.md) will manage the merge queue manually, or the [GitHub "munger"](https://github.com/kubernetes/test-infra/tree/master/mungegithub) submit-queue plugin will manage the merge queue automatically.
1. The PR enters the merge queue ([http://submit-queue.k8s.io](http://submit-queue.k8s.io))
1. The merge queue triggers a test re-run with the comment `@k8s-bot test this`
1. Author has signed the CLA (`cla: yes` label added to PR)
1. The merge queue triggers a test re-run with the comment `/test all [submit-queue is verifying that this PR is safe to merge]`
1. Author has signed the CLA (`cncf-cla: yes` label added to PR)
1. No changes made since last `lgtm` label applied
1. If tests fail, resolve issues by pushing edits to your PR branch
1. If the failure is a flake, a member can comment `@k8s-bot [e2e|unit] test this issue: #<flake issue>`
1. If the failure is a flake, anyone can comment `/retest` if the PR is trusted
1. If tests pass, the merge queue automatically merges the PR
That's the last step. Your PR is now merged.
@ -145,9 +149,11 @@ The Kubernetes developer community uses a variety of automation to manage pull r
## How the e2e Tests Work
The end-to-end tests will post the status results to the PR. If an e2e test fails, `k8s-ci-robot` will comment on the PR with the test history and the comment-command to re-run that test. e.g.
The end-to-end tests will post the status results to the PR. If an e2e test fails,
`@k8s-ci-robot` will comment on the PR with the test history and the
comment-command to re-run that test. e.g.
> The magic incantation to run this job again is @k8s-bot unit test this. Please help us cut down flakes by linking to an open flake issue when you hit one in your PR.
> The following tests failed, say /retest to rerun them all.
# Why was my PR closed?