85 lines
3.1 KiB
Markdown
85 lines
3.1 KiB
Markdown
# Overview
|
|
|
|
There are several steps to authoring or reviewing a pull request in Kubernetes.
|
|
Due to limitations on how GitHub permissions can be expressed, the Kubernetes
|
|
authors developed a workflow using comments to run tests and set labels
|
|
used for merging PRs. Merging a PR requires the following steps to be
|
|
completed before the PR will automatically be merged:
|
|
|
|
- Signing a CLA
|
|
- Setting release notes
|
|
- Having all e2e tests pass
|
|
- Getting an LGTM from a reviewer
|
|
|
|
# Master Branch Workflow
|
|
|
|
## Sign the CLA
|
|
|
|
If you have not already, the `k8s-ci-robot` will leave a comment with
|
|
instructions on how to sign the CLA.
|
|
|
|
**Important** the email you sign the CLA with must be the same email
|
|
attached to the commits in your PR. If it is not, you may need to change
|
|
the email and repush the commits.
|
|
|
|
## Set Release Notes
|
|
|
|
Every PR must be labeled either `release-note` or `release-note-none`.
|
|
This can be done by adding a release-note section to the pr description:
|
|
|
|
For PRs with a release note:
|
|
|
|
```release-note
|
|
Your release note here
|
|
```
|
|
|
|
|
|
|
|
For PRs without a release note:
|
|
|
|
```release-note
|
|
NONE
|
|
```
|
|
|
|
Release notes should be present for any PRs with user visible changes such as
|
|
bug-fixes, feature additions, and output format changes.
|
|
|
|
Additionally, commenting either `/release-note` or `/release-note-none`
|
|
will also set the `release-note` or `release-note-none` labels respectively.
|
|
|
|
## Run e2e Tests
|
|
|
|
End-to-end tests are run and post the status results to the PR. PRs authored by
|
|
regular contributors have the tests run automatically. PRs authored by new
|
|
community members require the reviewer to mark the tests as safe to run by
|
|
commenting `@k8s-bot ok to test`.
|
|
|
|
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.
|
|
|
|
## LGTM and Approval
|
|
|
|
A reviewer will be automatically assigned to your PR by the `k8s-merge-robot`. The
|
|
reviewer will leave comments on your PR. Once all comments have been addressed,
|
|
squash the commits and the reviewer will mark the PR as looking good. The PR will
|
|
also need to be approved by trusted approvers who are responsible for parts of the
|
|
code base. `k8s-merge-robot` will comment on your PR with the approval status of
|
|
your PR, along with suggesting the appropriate members who can do this approval.
|
|
|
|
## PR merge
|
|
|
|
After all of the checks have passed, the PR will enter the merge queue:
|
|
[http://submit-queue.k8s.io](http://submit-queue.k8s.io).
|
|
The merge queue re-runs the tests for PRs and then merges them if they pass. 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.
|
|
|
|
# Comment Commands Reference
|
|
|
|
Authors, reviewers, and owners can communicate with `k8s-ci-robot` by
|
|
commenting on a PR with the various commands entered in comments. Specific syntax
|
|
is available [here](https://github.com/kubernetes/test-infra/blob/master/commands.md)
|