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.

Makefile

@@ -42,15 +42,15 @@ export KUBE_GOLDFLAGS
 #   make all
 #   make all WHAT=cmd/kubelet GOFLAGS=-v
 all:
-	hack/build-go.sh $(WHAT)
+	@hack/make-rules/build.sh $(WHAT)
 .PHONY: all
 
 # Build ginkgo
 #
 # Example:
 # make ginkgo
 ginkgo:
-	hack/build-go.sh vendor/github.com/onsi/ginkgo/ginkgo	
+	hack/make-rules/build.sh vendor/github.com/onsi/ginkgo/ginkgo
 .PHONY: ginkgo
 
 # Runs all the presubmission verifications.
@@ -62,7 +62,7 @@ ginkgo:
 #   make verify
 #   make verify BRANCH=branch_x
 verify:
-	KUBE_VERIFY_GIT_BRANCH=$(BRANCH) hack/verify-all.sh -v
+	@KUBE_VERIFY_GIT_BRANCH=$(BRANCH) hack/make-rules/verify.sh -v
 .PHONY: verify
 
 # Build and run tests.
@@ -79,24 +79,24 @@ verify:
 #   make test
 #   make check WHAT=pkg/kubelet GOFLAGS=-v
 check test:
-	hack/test-go.sh $(WHAT) $(TESTS)
+	@hack/make-rules/test.sh $(WHAT) $(TESTS)
 .PHONY: check test
 
 # Build and run integration tests.
 #
 # Example:
-#   make test_integration
-test_integration:
-	hack/test-integration.sh
-.PHONY: test_integration test_integ
+#   make test-integration
+test-integration:
+	@hack/make-rules/test-integration.sh
+.PHONY: test-integration
 
 # Build and run end-to-end tests.
 #
 # Example:
-#   make test_e2e
-test_e2e:
-	go run hack/e2e.go -v --build --up --test --down
-.PHONY: test_e2e
+#   make test-e2e
+test-e2e: ginkgo
+	@go run hack/e2e.go -v --build --up --test --down
+.PHONY: test-e2e
 
 # Build and run node end-to-end tests.
 #
@@ -116,12 +116,20 @@ test_e2e:
 #  INSTANCE_PREFIX: for REMOTE=true only.  Instances created from images will have the name "${INSTANCE_PREFIX}-${IMAGE_NAME}".  Defaults to "test"/
 #
 # Example:
-#   make test_e2e_node FOCUS=kubelet SKIP=container
-#   make test_e2e_node REMOTE=true DELETE_INSTANCES=true
+#   make test-e2e-node FOCUS=kubelet SKIP=container
+#   make test-e2e-node REMOTE=true DELETE_INSTANCES=true
 # Build and run tests.
-test_e2e_node: ginkgo
-	hack/e2e-node-test.sh
-.PHONY: test_e2e_node
+test-e2e-node: ginkgo
+	@hack/make-rules/test-e2e-node.sh
+.PHONY: test-e2e-node
+
+# Build and run cmdline tests.
+#
+# Example:
+#   make test-cmd
+test-cmd:
+	@hack/make-rules/test-cmd.sh
+.PHONY: test-cmd
 
 # Remove all build artifacts.
 #
@@ -139,30 +147,26 @@ clean:
 #   WHAT: Directory names to vet.  All *.go files under these
 #     directories will be vetted.  If not specified, "everything" will be
 #     vetted.
-#   TESTS: Same as WHAT.
-#   GOFLAGS: Extra flags to pass to 'go' when building.
-#   GOLDFLAGS: Extra linking flags to pass to 'go' when building.
 #
 # Example:
 #   make vet
 #   make vet WHAT=pkg/kubelet
 vet:
-	hack/verify-govet.sh $(WHAT) $(TESTS)
+	@hack/make-rules/vet.sh $(WHAT)
 .PHONY: vet
 
 # Build a release
 #
 # Example:
 #   make release
 release:
-	build/release.sh
+	@build/release.sh
 .PHONY: release
 
 # Build a release, but skip tests
 #
 # Example:
 #   make release-skip-tests
 release-skip-tests quick-release:
-	KUBE_RELEASE_RUN_TESTS=n KUBE_FASTBUILD=true build/release.sh
+	@KUBE_RELEASE_RUN_TESTS=n KUBE_FASTBUILD=true build/release.sh
 .PHONY: release-skip-tests quick-release
-

build/README.md

@@ -24,10 +24,11 @@ There is also early support for building Docker "run" containers
 The following scripts are found in the `build/` directory:
 
 * `run.sh`: Run a command in a build docker container.  Common invocations:
-  *  `run.sh hack/build-go.sh`: Build just linux binaries in the container.  Pass options and packages as necessary.
+  *  `run.sh make`: Build just linux binaries in the container.  Pass options and packages as necessary.
   *  `run.sh hack/build-cross.sh`: Build all binaries for all platforms
-  *  `run.sh hack/test-go.sh`: Run all unit tests
-  *  `run.sh hack/test-integration.sh`: Run integration test
+  *  `run.sh make test`: Run all unit tests
+  *  `run.sh make test-integration`: Run integration test
+  *  `run.sh make test-cmd`: Run CLI tests
 * `copy-output.sh`: This will copy the contents of `_output/dockerized/bin` from any remote Docker container to the local `_output/dockerized/bin`.  Right now this is only necessary on Mac OS X with `boot2docker` when your git repo isn't under `/Users`.
 * `make-clean.sh`: Clean out the contents of `_output/dockerized` and remove any local built container images.
 * `shell.sh`: Drop into a `bash` shell in a build container with a snapshot of the current repo code.

build/release.sh

@@ -33,8 +33,8 @@ kube::build::build_image
 kube::build::run_build_command hack/build-cross.sh
 
 if [[ $KUBE_RELEASE_RUN_TESTS =~ ^[yY]$ ]]; then
-  kube::build::run_build_command hack/test-go.sh
-  kube::build::run_build_command hack/test-integration.sh
+  kube::build::run_build_command make test
+  kube::build::run_build_command make test-integration
 fi
 
 if [[ "${FEDERATION:-}" == "true" ]];then

cluster/azure-legacy/util.sh

@@ -514,7 +514,7 @@ function kube-down {
 #}
 
 # -----------------------------------------------------------------------------
-# Cluster specific test helpers used from hack/e2e-test.sh
+# Cluster specific test helpers
 
 # Execute prior to running tests to build a release if required for env.
 #

contrib/mesos/ci/test-integration.sh

@@ -31,4 +31,4 @@ TEST_ARGS="$@"
 
 KUBE_ROOT=$(cd "$(dirname "${BASH_SOURCE}")/../../.." && pwd)
 
-"${KUBE_ROOT}/contrib/mesos/ci/run.sh" make clean test_integration ${TEST_ARGS}
+"${KUBE_ROOT}/contrib/mesos/ci/run.sh" make clean test-integration ${TEST_ARGS}

contrib/mesos/docs/ha.md

@@ -155,7 +155,7 @@ K8SM_IMAGE_NAME=haih/k8sm
 git clone https://github.com/mesosphere/kubernetes
 cd kubernetes
 git checkout release-v0.7-v1.1
-KUBERNETES_CONTRIB=mesos build/run.sh hack/build-go.sh
+KUBERNETES_CONTRIB=mesos build/run.sh make
 cd ..
 sudo docker build -t $K8SM_IMAGE_NAME --no-cache .
 EOF

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,47 +124,47 @@ 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.
 
 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)
 
 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
 
 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
 
 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
 
 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
 ```