From 793488ebab93cd98c436bcf08de0845efe38ec1a Mon Sep 17 00:00:00 2001 From: Tim Hockin Date: Tue, 24 May 2016 08:40:44 -0700 Subject: 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. --- adding-an-APIGroup.md | 4 ++-- development.md | 11 ++++++++--- e2e-node-tests.md | 24 ++++++++++++------------ pull-requests.md | 6 +++--- releasing.md | 10 ++++++---- running-locally.md | 2 +- testing.md | 41 +++++++++++++++++++++++------------------ 7 files changed, 55 insertions(+), 43 deletions(-) diff --git a/adding-an-APIGroup.md b/adding-an-APIGroup.md index cefa8564..f05009dd 100644 --- a/adding-an-APIGroup.md +++ b/adding-an-APIGroup.md @@ -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 in tests through testapi.``; -2. Add your "group/version" to `KUBE_API_VERSIONS` and `KUBE_TEST_API_VERSIONS` -in hack/test-go.sh. +2. Add your "group/version" to `KUBE_TEST_API_VERSIONS` in + hack/make-rules/test.sh and hack/make-rules/test-integration.sh TODO: Add a troubleshooting section. diff --git a/development.md b/development.md index 82014e7c..4c00072e 100644 --- a/development.md +++ b/development.md @@ -71,11 +71,16 @@ up a GOPATH. To build Kubernetes using your local Go development environment (generate linux binaries): - hack/build-go.sh +```sh + make +``` + You may pass build options and packages to the script as necessary. To build binaries for all platforms: +```sh hack/build-cross.sh +``` ## Workflow @@ -314,8 +319,8 @@ Three basic commands let you run unit, integration and/or e2e tests: ```sh cd kubernetes -hack/test-go.sh # Run unit tests -hack/test-integration.sh # Run integration tests, requires etcd +make test # Run unit tests +make test-integration # Run integration tests, requires etcd go run hack/e2e.go -v --build --up --test --down # Run e2e tests ``` diff --git a/e2e-node-tests.md b/e2e-node-tests.md index 03ee4811..f4713855 100644 --- a/e2e-node-tests.md +++ b/e2e-node-tests.md @@ -57,7 +57,7 @@ Prerequisites: From the Kubernetes base directory, run: ```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: @@ -87,7 +87,7 @@ Prerequisites: Run: ```sh -make test_e2e_node REMOTE=true +make test-e2e-node REMOTE=true ``` This will: @@ -124,7 +124,7 @@ provided by the default image. List the available test images using gcloud. ```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. @@ -132,7 +132,7 @@ This will output a list of the available images for the default image project. Then run: ```sh -make test_e2e_node REMOTE=true IMAGES="" +make test-e2e-node REMOTE=true IMAGES="" ``` ## Run tests against a running GCE instance (not an image) @@ -140,7 +140,7 @@ make test_e2e_node REMOTE=true 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. ```sh -make test_e2e_node REMOTE=true HOSTS="" +make test-e2e-node REMOTE=true HOSTS="" ``` ## Delete instance after tests run @@ -148,7 +148,7 @@ make test_e2e_node REMOTE=true HOSTS="" This is useful if you want recreate the instance for each test run to trigger flakes related to starting the instance. ```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 @@ -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. ```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 @@ -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. ```sh -make test_e2e_node REMOTE=true IMAGE_PROJECT="" IMAGES="" +make test-e2e-node REMOTE=true IMAGE_PROJECT="" IMAGES="" ``` 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. ```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 @@ -186,13 +186,13 @@ make test_e2e_node REMOTE=true INSTANCE_PREFIX="my-prefix" To run tests matching a regex: ```sh -make test_e2e_node REMOTE=true FOCUS="" +make test-e2e-node REMOTE=true FOCUS="" ``` To run tests NOT matching a regex: ```sh -make test_e2e_node REMOTE=true SKIP="" +make test-e2e-node REMOTE=true SKIP="" ``` ## 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.** ```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. diff --git a/pull-requests.md b/pull-requests.md index 2037b410..40705971 100644 --- a/pull-requests.md +++ b/pull-requests.md @@ -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: * Enable [pre-commit hooks](development.md#committing-changes-to-your-fork) and verify they pass. -* Verify `hack/verify-all.sh` passes. -* Verify `hack/test-go.sh` passes. -* Verify `hack/test-integration.sh` passes. +* Verify `make verify` passes. +* Verify `make test` passes. +* Verify `make test-integration.sh` passes. ## Release Notes diff --git a/releasing.md b/releasing.md index 2c8b5d00..eb48f469 100644 --- a/releasing.md +++ b/releasing.md @@ -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 authoritative source on how version injection works.* -Kubernetes may be built from either a git tree (using `hack/build-go.sh`) or -from a tarball (using either `hack/build-go.sh` or `go install`) or directly by -the Go native build system (using `go get`). +Kubernetes may be built from either a git tree or from a tarball. We use +`make` to encapsulate a number of build steps into a single command. This +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 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 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 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 diff --git a/running-locally.md b/running-locally.md index 517b12c8..0e56456e 100644 --- a/running-locally.md +++ b/running-locally.md @@ -170,7 +170,7 @@ You are running a single node setup. This has the limitation of only supporting ```sh cd kubernetes -hack/build-go.sh +make hack/local-up-cluster.sh ``` diff --git a/testing.md b/testing.md index dba01c10..3d7fb452 100644 --- a/testing.md +++ b/testing.md @@ -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 -The `hack/test-go.sh` script is the entrypoint for running the unit tests that -ensures that `GOPATH` is set up correctly. If you have `GOPATH` set up -correctly, you can also just use `go test` directly. +`make test` is the entrypoint for running the unit tests that ensures that +`GOPATH` is set up correctly. If you have `GOPATH` set up correctly, you can +also just use `go test` directly. ```sh cd kubernetes -hack/test-go.sh # Run all unit tests. +make test # Run all 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 -The `hack/test-go.sh` script accepts packages as arguments; the -`k8s.io/kubernetes` prefix is added automatically to these: +`make test` accepts packages as arguments; the `k8s.io/kubernetes` prefix is +added automatically to these: ```sh -hack/test-go.sh pkg/api # run tests for pkg/api -hack/test-go.sh pkg/api pkg/kubelet # run tests for pkg/api and pkg/kubelet +make test WHAT=pkg/api # run tests for pkg/api +``` + +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: ```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 @@ -121,10 +126,10 @@ regular expression for the name of the test that should be run. ```sh # 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 -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 @@ -137,7 +142,7 @@ You can do this efficiently. ```sh # 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). @@ -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: ```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 @@ -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: ```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 @@ -224,14 +229,14 @@ for those internal etcd instances with the `TEST_ETCD_DIR` environment variable. ### 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 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. ```sh -hack/test-integration.sh # Run all integration tests. +make test-integration # Run all integration tests. ``` 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 # 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 -- cgit v1.2.3