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

Use make as the main build tool 

This allows us to start building real dependencies into Makefile.

Leave old hack/* scripts in place but advise to use 'make'.  There are a few
rules that call things like 'go run' or 'build/*' that I left as-is for now.
This commit is contained in:
Tim Hockin 2016-05-24 08:40:44 -07:00
parent 84f3c5486f
commit 793488ebab
7 changed files with 55 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
adding-an-APIGroup.md
View File

@ -119,8 +119,8 @@ pkg/kubectl/cmd/util/factory.go.
1. Add your group in pkg/api/testapi/testapi.go, then you can access the group 1. Add your group in pkg/api/testapi/testapi.go, then you can access the group
in tests through testapi.`<group>`; in tests through testapi.`<group>`;
2. Add your "group/version" to `KUBE_API_VERSIONS` and `KUBE_TEST_API_VERSIONS` 2. Add your "group/version" to `KUBE_TEST_API_VERSIONS` in
in hack/test-go.sh. hack/make-rules/test.sh and hack/make-rules/test-integration.sh
TODO: Add a troubleshooting section. TODO: Add a troubleshooting section.

11
development.md
View File

@ -71,11 +71,16 @@ up a GOPATH.
To build Kubernetes using your local Go development environment (generate linux To build Kubernetes using your local Go development environment (generate linux
binaries): binaries):
hack/build-go.sh ```sh
make
```
You may pass build options and packages to the script as necessary. To build You may pass build options and packages to the script as necessary. To build
binaries for all platforms: binaries for all platforms:
```sh
hack/build-cross.sh hack/build-cross.sh
```
## Workflow ## Workflow
@ -314,8 +319,8 @@ Three basic commands let you run unit, integration and/or e2e tests:
```sh ```sh
cd kubernetes cd kubernetes
hack/test-go.sh # Run unit tests make test # Run unit tests
hack/test-integration.sh # Run integration tests, requires etcd make test-integration # Run integration tests, requires etcd
go run hack/e2e.go -v --build --up --test --down # Run e2e tests go run hack/e2e.go -v --build --up --test --down # Run e2e tests
``` ```

24
e2e-node-tests.md
View File

@ -57,7 +57,7 @@ Prerequisites:
From the Kubernetes base directory, run: From the Kubernetes base directory, run:
```sh ```sh
make test_e2e_node make test-e2e-node
``` ```
This will: run the *ginkgo* binary against the subdirectory *test/e2e_node*, which will in turn: This will: run the *ginkgo* binary against the subdirectory *test/e2e_node*, which will in turn:
@ -87,7 +87,7 @@ Prerequisites:
Run: Run:
```sh ```sh
make test_e2e_node REMOTE=true make test-e2e-node REMOTE=true
``` ```
This will: This will:
@ -124,7 +124,7 @@ provided by the default image.
List the available test images using gcloud. List the available test images using gcloud.
```sh ```sh
make test_e2e_node LIST_IMAGES=true make test-e2e-node LIST_IMAGES=true
``` ```
This will output a list of the available images for the default image project. This will output a list of the available images for the default image project.
@ -132,7 +132,7 @@ This will output a list of the available images for the default image project.
Then run: Then run:
```sh ```sh
make test_e2e_node REMOTE=true IMAGES="<comma-separated-list-images>" make test-e2e-node REMOTE=true IMAGES="<comma-separated-list-images>"
``` ```
## Run tests against a running GCE instance (not an image) ## Run tests against a running GCE instance (not an image)
@ -140,7 +140,7 @@ make test_e2e_node REMOTE=true IMAGES="<comma-separated-list-images>"
This is useful if you have an host instance running already and want to run the tests there instead of on a new instance. This is useful if you have an host instance running already and want to run the tests there instead of on a new instance.
```sh ```sh
make test_e2e_node REMOTE=true HOSTS="<comma-separated-list-of-hostnames>" make test-e2e-node REMOTE=true HOSTS="<comma-separated-list-of-hostnames>"
``` ```
## Delete instance after tests run ## Delete instance after tests run
@ -148,7 +148,7 @@ make test_e2e_node REMOTE=true HOSTS="<comma-separated-list-of-hostnames>"
This is useful if you want recreate the instance for each test run to trigger flakes related to starting the instance. This is useful if you want recreate the instance for each test run to trigger flakes related to starting the instance.
```sh ```sh
make test_e2e_node REMOTE=true DELETE_INSTANCES=true make test-e2e-node REMOTE=true DELETE_INSTANCES=true
``` ```
## Keep instance, test binaries, and *processes* around after tests run ## Keep instance, test binaries, and *processes* around after tests run
@ -156,7 +156,7 @@ make test_e2e_node REMOTE=true DELETE_INSTANCES=true
This is useful if you want to manually inspect or debug the kubelet process run as part of the tests. This is useful if you want to manually inspect or debug the kubelet process run as part of the tests.
```sh ```sh
make test_e2e_node REMOTE=true CLEANUP=false make test-e2e-node REMOTE=true CLEANUP=false
``` ```
## Run tests using an image in another project ## Run tests using an image in another project
@ -164,7 +164,7 @@ make test_e2e_node REMOTE=true CLEANUP=false
This is useful if you want to create your own host image in another project and use it for testing. This is useful if you want to create your own host image in another project and use it for testing.
```sh ```sh
make test_e2e_node REMOTE=true IMAGE_PROJECT="<name-of-project-with-images>" IMAGES="<image-name>" make test-e2e-node REMOTE=true IMAGE_PROJECT="<name-of-project-with-images>" IMAGES="<image-name>"
``` ```
Setting up your own host image may require additional steps such as installing etcd or docker. See Setting up your own host image may require additional steps such as installing etcd or docker. See
@ -176,7 +176,7 @@ This is useful if you want to create instances using a different name so that yo
test in parallel against different instances of the same image. test in parallel against different instances of the same image.
```sh ```sh
make test_e2e_node REMOTE=true INSTANCE_PREFIX="my-prefix" make test-e2e-node REMOTE=true INSTANCE_PREFIX="my-prefix"
``` ```
# Additional Test Options for both Remote and Local execution # Additional Test Options for both Remote and Local execution
@ -186,13 +186,13 @@ make test_e2e_node REMOTE=true INSTANCE_PREFIX="my-prefix"
To run tests matching a regex: To run tests matching a regex:
```sh ```sh
make test_e2e_node REMOTE=true FOCUS="<regex-to-match>" make test-e2e-node REMOTE=true FOCUS="<regex-to-match>"
``` ```
To run tests NOT matching a regex: To run tests NOT matching a regex:
```sh ```sh
make test_e2e_node REMOTE=true SKIP="<regex-to-match>" make test-e2e-node REMOTE=true SKIP="<regex-to-match>"
``` ```
## Run tests continually until they fail ## Run tests continually until they fail
@ -202,7 +202,7 @@ run the tests until they fail. **Note: this will only perform test setup once (
less useful for catching flakes related creating the instance from an image.** less useful for catching flakes related creating the instance from an image.**
```sh ```sh
make test_e2e_node REMOTE=true RUN_UNTIL_FAILURE=true make test-e2e-node REMOTE=true RUN_UNTIL_FAILURE=true
``` ```
# Notes on tests run by the Kubernetes project during pre-, post- submit. # Notes on tests run by the Kubernetes project during pre-, post- submit.

6
pull-requests.md
View File

@ -69,9 +69,9 @@ Additionally, for infrequent or new contributors, we require the on call to appl
The following will save time for both you and your reviewer: The following will save time for both you and your reviewer:
* Enable [pre-commit hooks](development.md#committing-changes-to-your-fork) and verify they pass. * Enable [pre-commit hooks](development.md#committing-changes-to-your-fork) and verify they pass.
* Verify `hack/verify-all.sh` passes. * Verify `make verify` passes.
* Verify `hack/test-go.sh` passes. * Verify `make test` passes.
* Verify `hack/test-integration.sh` passes. * Verify `make test-integration.sh` passes.
## Release Notes ## Release Notes

10
releasing.md
View File

@ -257,9 +257,11 @@ been automated that need to happen after the branch has been cut:
*Please note that this information may be out of date. The scripts are the *Please note that this information may be out of date. The scripts are the
authoritative source on how version injection works.* authoritative source on how version injection works.*
Kubernetes may be built from either a git tree (using `hack/build-go.sh`) or Kubernetes may be built from either a git tree or from a tarball. We use
from a tarball (using either `hack/build-go.sh` or `go install`) or directly by `make` to encapsulate a number of build steps into a single command. This
the Go native build system (using `go get`). includes generating code, which means that tools like `go build` might work
(once files are generated) but might be using stale generated code. `make` is
the supported way to build.
When building from git, we want to be able to insert specific information about When building from git, we want to be able to insert specific information about
the build tree at build time. In particular, we want to use the output of `git the build tree at build time. In particular, we want to use the output of `git
@ -294,7 +296,7 @@ yield binaries that will identify themselves as `v0.4-dev` and will not be able
to provide you with a SHA1. to provide you with a SHA1.
To add the extra versioning information when building from git, the To add the extra versioning information when building from git, the
`hack/build-go.sh` script will gather that information (using `git describe` and `make` build will gather that information (using `git describe` and
`git rev-parse`) and then create a `-ldflags` string to pass to `go install` and `git rev-parse`) and then create a `-ldflags` string to pass to `go install` and
tell the Go linker to override the contents of those variables at build time. It tell the Go linker to override the contents of those variables at build time. It
can, for instance, tell it to override `gitVersion` and set it to can, for instance, tell it to override `gitVersion` and set it to

2
running-locally.md
View File

@ -170,7 +170,7 @@ You are running a single node setup. This has the limitation of only supporting
```sh ```sh
cd kubernetes cd kubernetes
hack/build-go.sh make
hack/local-up-cluster.sh hack/local-up-cluster.sh
``` ```

41
testing.md
View File

@ -83,13 +83,13 @@ passing, so it is often a good idea to make sure the e2e tests work as well.
### Run all unit tests ### Run all unit tests
The `hack/test-go.sh` script is the entrypoint for running the unit tests that `make test` is the entrypoint for running the unit tests that ensures that
ensures that `GOPATH` is set up correctly. If you have `GOPATH` set up `GOPATH` is set up correctly. If you have `GOPATH` set up correctly, you can
correctly, you can also just use `go test` directly. also just use `go test` directly.
```sh ```sh
cd kubernetes cd kubernetes
hack/test-go.sh # Run all unit tests. make test # Run all unit tests.
``` ```
### Set go flags during unit tests ### Set go flags during unit tests
@ -99,18 +99,23 @@ You can set [go flags](https://golang.org/cmd/go/) by setting the
### Run unit tests from certain packages ### Run unit tests from certain packages
The `hack/test-go.sh` script accepts packages as arguments; the `make test` accepts packages as arguments; the `k8s.io/kubernetes` prefix is
`k8s.io/kubernetes` prefix is added automatically to these: added automatically to these:
```sh ```sh
hack/test-go.sh pkg/api # run tests for pkg/api make test WHAT=pkg/api # run tests for pkg/api
hack/test-go.sh pkg/api pkg/kubelet # run tests for pkg/api and pkg/kubelet ```
To run multiple targets you need quotes:
```sh
make test WHAT="pkg/api pkg/kubelet" # run tests for pkg/api and pkg/kubelet
``` ```
In a shell, it's often handy to use brace expansion: In a shell, it's often handy to use brace expansion:
```sh ```sh
hack/test-go.sh pkg/{api,kubelet} # run tests for pkg/api and pkg/kubelet make test WHAT=pkg/{api,kubelet} # run tests for pkg/api and pkg/kubelet
``` ```
### Run specific unit test cases in a package ### Run specific unit test cases in a package
@ -121,10 +126,10 @@ regular expression for the name of the test that should be run.
```sh ```sh
# Runs TestValidatePod in pkg/api/validation with the verbose flag set # Runs TestValidatePod in pkg/api/validation with the verbose flag set
KUBE_GOFLAGS="-v" KUBE_TEST_ARGS='-run ^TestValidatePod$' hack/test-go.sh pkg/api/validation make test WHAT=pkg/api/validation KUBE_GOFLAGS="-v" KUBE_TEST_ARGS='-run ^TestValidatePod$'
# Runs tests that match the regex ValidatePod|ValidateConfigMap in pkg/api/validation # Runs tests that match the regex ValidatePod|ValidateConfigMap in pkg/api/validation
KUBE_GOFLAGS="-v" KUBE_TEST_ARGS="-run ValidatePod\|ValidateConfigMap$" hack/test-go.sh pkg/api/validation make test WHAT=pkg/api/validation KUBE_GOFLAGS="-v" KUBE_TEST_ARGS="-run ValidatePod\|ValidateConfigMap$"
``` ```
For other supported test flags, see the [golang For other supported test flags, see the [golang
@ -137,7 +142,7 @@ You can do this efficiently.
```sh ```sh
# Have 2 workers run all tests 5 times each (10 total iterations). # Have 2 workers run all tests 5 times each (10 total iterations).
hack/test-go.sh -p 2 -i 5 make test PARALLEL=2 ITERATION=5
``` ```
For more advanced ideas please see [flaky-tests.md](flaky-tests.md). For more advanced ideas please see [flaky-tests.md](flaky-tests.md).
@ -149,7 +154,7 @@ Currently, collecting coverage is only supported for the Go unit tests.
To run all unit tests and generate an HTML coverage report, run the following: To run all unit tests and generate an HTML coverage report, run the following:
```sh ```sh
KUBE_COVER=y hack/test-go.sh make test KUBE_COVER=y
``` ```
At the end of the run, an HTML report will be generated with the path At the end of the run, an HTML report will be generated with the path
@ -159,7 +164,7 @@ To run tests and collect coverage in only one package, pass its relative path
under the `kubernetes` directory as an argument, for example: under the `kubernetes` directory as an argument, for example:
```sh ```sh
KUBE_COVER=y hack/test-go.sh pkg/kubectl make test WHAT=pkg/kubectl KUBE_COVER=y
``` ```
Multiple arguments can be passed, in which case the coverage results will be Multiple arguments can be passed, in which case the coverage results will be
@ -224,14 +229,14 @@ for those internal etcd instances with the `TEST_ETCD_DIR` environment variable.
### Run integration tests ### Run integration tests
The integration tests are run using the `hack/test-integration.sh` script. The integration tests are run using `make test-integration`.
The Kubernetes integration tests are writting using the normal golang testing The Kubernetes integration tests are writting using the normal golang testing
package but expect to have a running etcd instance to connect to. The `test- package but expect to have a running etcd instance to connect to. The `test-
integration.sh` script wraps `hack/test-go.sh` and sets up an etcd instance integration.sh` script wraps `make test` and sets up an etcd instance
for the integration tests to use. for the integration tests to use.
```sh ```sh
hack/test-integration.sh # Run all integration tests. make test-integration # Run all integration tests.
``` ```
This script runs the golang tests in package This script runs the golang tests in package
@ -244,7 +249,7 @@ You can use also use the `KUBE_TEST_ARGS` environment variable with the `hack
```sh ```sh
# Run integration test TestPodUpdateActiveDeadlineSeconds with the verbose flag set. # Run integration test TestPodUpdateActiveDeadlineSeconds with the verbose flag set.
KUBE_GOFLAGS="-v" KUBE_TEST_ARGS="-run ^TestPodUpdateActiveDeadlineSeconds$" hack/test-integration.sh make test-integration KUBE_GOFLAGS="-v" KUBE_TEST_ARGS="-run ^TestPodUpdateActiveDeadlineSeconds$"
``` ```
If you set `KUBE_TEST_ARGS`, the test case will be run with only the `v1` API If you set `KUBE_TEST_ARGS`, the test case will be run with only the `v1` API