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

Merge pull request #5450 from slettner/fix-spell-error-contributor-guide 

Fixed spell errors contributors/devel/development.md
This commit is contained in:
Kubernetes Prow Robot 2021-02-01 15:20:29 -08:00 committed by GitHub
parent 069765f4e3 fbef72efb8
commit 89416c7db0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
contributors/devel/development.md
View File

@ -50,7 +50,7 @@ resilient behavior. For example: if your patch causes a controller to better
handle inconsistent data, make a mock object which returns incorrect data a few handle inconsistent data, make a mock object which returns incorrect data a few
times and verify the controller's new behaviour. times and verify the controller's new behaviour.
### Is this a performance improvement ? ### Is this a performance improvement?
Performance bug reports MUST include data that demonstrates the bug. Without Performance bug reports MUST include data that demonstrates the bug. Without
data, the issue will be closed. You can measure performance using kubemark, data, the issue will be closed. You can measure performance using kubemark,
@ -98,7 +98,7 @@ or all of these before you get started.
Since performance improvements can be empirically measured, you should follow Since performance improvements can be empirically measured, you should follow
the "scientific method" of creating a hypothesis, collecting data, and then the "scientific method" of creating a hypothesis, collecting data, and then
revising your hypothesis. The above issues do this transparently, using figures revising your hypothesis. The above issues do this transparently, using figures
and data rather then conjecture. Notice that the problem is analyzed and a and data rather than conjecture. Notice that the problem is analyzed and a
correct solution is created before a single line of code is reviewed. correct solution is created before a single line of code is reviewed.
## Building Kubernetes with Docker ## Building Kubernetes with Docker
@ -260,7 +260,7 @@ development environment, please follow the instructions in the
Confirm that your `GOPATH` and `GOBIN` environment variables are Confirm that your `GOPATH` and `GOBIN` environment variables are
correctly set as detailed in correctly set as detailed in
[How to Write Go Code](https://golang.org/doc/code.html) before [How to Write Go Code](https://golang.org/doc/code.html) before
prodeding. proceeding.
**Note:** Building and developing Kubernetes requires a very recent **Note:** Building and developing Kubernetes requires a very recent
version of Go. Please install the newest stable version available for version of Go. Please install the newest stable version available for
@ -306,7 +306,7 @@ You are now ready to clone the Kubernetes git repository. See the [GitHub Workfl
#### etcd #### etcd
To test Kubernetes, you will need to install a recent version of [etcd](https://etcd.io/), a consistent and highly-available key value store. To install a local version of etcd, run the following command in your Kubernetes working directory. To test Kubernetes, you will need to install a recent version of [etcd](https://etcd.io/), a consistent and highly-available key-value store. To install a local version of etcd, run the following command in your Kubernetes working directory.
```sh ```sh
./hack/install-etcd.sh ./hack/install-etcd.sh
@ -374,9 +374,8 @@ make cross KUBE_BUILD_PLATFORMS=windows/amd64
## A Quick Start for Testing Kubernetes ## A Quick Start for Testing Kubernetes
Kubernetes only merges pull requests when unit, integration, and e2e tests are Because kubernetes only merges pull requests when unit, integration, and e2e tests are
passing, so it is important that your development environment can passing, your development environment needs to run all tests successfully. While this quick start will get you going,
successfully run all tests. While this quick start will get you going,
to really understand the testing infrastructure, read the to really understand the testing infrastructure, read the
[Testing Guide](sig-testing/testing.md) and check out the [Testing Guide](sig-testing/testing.md) and check out the
[SIG Architecture developer guide material](README.md#sig-testing). [SIG Architecture developer guide material](README.md#sig-testing).
@ -391,8 +390,7 @@ mentioned here by running `make help`.
### Presubmission Verification ### Presubmission Verification
Presubmission verification provides a battery of checks and tests to Presubmission verification provides a battery of checks and tests to
give your pull request the best chance of being accepted. It is give your pull request the best chance of being accepted. Developers need to run as many verification tests as possible
important for developers to run as many verification tests as posible
locally. locally.
You can view a list of all verification tests in `hack/verify-*.sh` You can view a list of all verification tests in `hack/verify-*.sh`
@ -426,7 +424,7 @@ make test
``` ```
You can also use the `WHAT` option to control which packages and You can also use the `WHAT` option to control which packages and
subsystems are testing, and use `GOFLAGS` to change how tests are subsystems are testing and use `GOFLAGS` to change how tests are
run. For example, to run unit tests verbosely against just one run. For example, to run unit tests verbosely against just one
package, use a command like this: package, use a command like this:
@ -437,7 +435,7 @@ make test WHAT=./pkg/apis/core/helper GOFLAGS=-v
### Integration Tests ### Integration Tests
All integration tests need to pass for a pull request to be All integration tests need to pass for a pull request to be
accepted. Note that for this stage in particular, it is important that accepted. Note that for this stage, in particular, it is important that
[etcd](#etcd) be properly installed. Without it, integration testing [etcd](#etcd) be properly installed. Without it, integration testing
will fail. will fail.
@ -452,7 +450,7 @@ To learn more about integration testing, read the
### E2E Tests ### E2E Tests
End-to-end (E2E) tests provide a mechanism to test end-to-end behavior End-to-end (E2E) tests provide a mechanism to test the end-to-end behavior
of the system. The primary objective of the E2E tests is to ensure of the system. The primary objective of the E2E tests is to ensure
consistent and reliable behavior of the Kubernetes code base, consistent and reliable behavior of the Kubernetes code base,
especially in areas where unit and integration tests are insufficient. especially in areas where unit and integration tests are insufficient.