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

Merge pull request #4345 from vishakhanihore/okto 

feat: Documentation about ok-to-test label
This commit is contained in:
Kubernetes Prow Robot 2019-12-24 07:21:30 -08:00 committed by GitHub
parent 62175b6407 a886fa31e9
commit 1fe5e60567
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 20 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
contributors/guide/pull-requests.md
View File

@ -10,6 +10,7 @@ This doc explains the process and best practices for submitting a pull request t
- [Run Local Verifications](#run-local-verifications)
- [The Pull Request Submit Process](#the-pull-request-submit-process)
- [The Testing and Merge Workflow](#the-testing-and-merge-workflow)
- [More About Ok-To-Test](#more-about-ok-to-test)
- [Marking Unfinished Pull Requests](#marking-unfinished-pull-requests)
- [Pull Requests and the Release Cycle](#pull-requests-and-the-release-cycle)
- [Comment Commands Reference](#comment-commands-reference)
@ -109,6 +110,25 @@ easily see all criteria that are not being met and address them.
That's the last step. Your pull request is now merged.
## More About `Ok-To-Test`
- The ok-to-test label is applied by org members to PRs from external contributors, it signals that the PR can be tested.
- For a Contributor, an `ok-to-test` label means the regular CI tests will be run for their PR.
- For the reviewer or the member, labelling the PR with `ok-to-test` it means a lot more:
- They need to take care if the PR is not a wastage of our `CI/CD` resources.
- Is the PR worth testing or does it need more changes before going through the `CI/CD` process?
- Is the PR getting used to run malicious code to misuse our resources ?
- An `ok-to-test` label may reduce the workload and smoothens the contributors experience as they can know if there is any failing test. If there is, you can fix the test and they don't have to wait for a long time to get a review from `maintainer/assignee`.
- There are various other factors on which labelling of `ok-to-test` depends :
- Size of PR :
- If the PR is of `size/S` or `size/M` which is just to fix a grammatical error or spelling mistake, the reviewer can trigger the `CI/CD` without having a second thought.
- If the PR is of `size/XXL` which aims at adding a new feature, a new API endpoint or any new substantial feature. There needs to other conventions & process to be followed regarding the change made. Hence it may have a slight to delay to get labelled with `ok-to-test`.
- Other org members who are not assigned to the following PR may also label `ok-to-test` , if the change is small.
- If the PR is labelled with `cncf-cla: no`, then it is better to wait before labelling `ok-to-test`.
- PRs with tag `do-not-merge/hold` or `needs-rebase` should make the appropriate changes before the PR can be labelled `ok-to-test`.
- PRs created by mistake without to meaningful change of code should not be labelled `ok-to-test` and closed.
## Marking Unfinished Pull Requests
If you want to solicit reviews before the implementation of your pull request is complete, you should hold your pull request to ensure that Tide does not pick it up and attempt to merge it. There are two methods to achieve this: