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.

docs/devel/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.`<group>`;
 
-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.
 

docs/devel/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
 ```
 

docs/devel/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="<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)
@@ -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.
 
 ```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
@@ -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.
 
 ```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="<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
@@ -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="<regex-to-match>"
+make test-e2e-node REMOTE=true FOCUS="<regex-to-match>"
 ```
 
 To run tests NOT matching a regex:
 
 ```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
@@ -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.

docs/devel/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
 

docs/devel/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

docs/devel/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
 ```
 

docs/devel/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