rename build/ to build-tools/

docs/devel/bazel.md

@@ -37,13 +37,13 @@ can be found [here](https://www.bazel.io/versions/master/docs/install.html).
 To build docker images for the components, run:
 
 ```
-$ bazel build //build/...
+$ bazel build //build-tools/...
 ```
 
 To run many of the unit tests, run:
 
 ```
-$ bazel test //cmd/... //build/... //pkg/... //federation/... //plugin/...
+$ bazel test //cmd/... //build-tools/... //pkg/... //federation/... //plugin/...
 ```
 
 To update automanaged build files, run:

docs/devel/cherry-picks.md

@@ -79,7 +79,7 @@ tracking the tool to automate the batching procedure.
 #### Cherrypicking a doc change
 
 If you are cherrypicking a change which adds a doc, then you also need to run
-`build/versionize-docs.sh` in the release branch to versionize that doc.
+`build-tools/versionize-docs.sh` in the release branch to versionize that doc.
 Ideally, just running `hack/cherry_pick_pull.sh` should be enough, but we are
 not there yet: [#18861](https://github.com/kubernetes/kubernetes/issues/18861)
 
@@ -89,7 +89,7 @@ running `hack/cherry_pick_pull.sh` and before merging the PR:
 ```
 $ git checkout -b automated-cherry-pick-of-#123456-upstream-release-3.14
 origin/automated-cherry-pick-of-#123456-upstream-release-3.14
-$ ./build/versionize-docs.sh release-3.14
+$ ./build-tools/versionize-docs.sh release-3.14
 $ git commit -a -m "Running versionize docs"
 $ git push origin automated-cherry-pick-of-#123456-upstream-release-3.14
 ```

docs/devel/development.md

@@ -49,7 +49,7 @@ branch, but release branches of Kubernetes should not change.
 
 Official releases are built using Docker containers. To build Kubernetes using
 Docker please follow [these instructions]
-(http://releases.k8s.io/HEAD/build/README.md).
+(http://releases.k8s.io/HEAD/build-tools/README.md).
 
 ## Building Kubernetes on a local OS/shell environment
 
@@ -142,10 +142,10 @@ bump to a minor release version for security updates.
 Since kubernetes is mostly built and tested in containers, there are a few
 unique places you need to update the go version.
 
-- The image for cross compiling in [build/build-image/cross/](../../build/build-image/cross/). The `VERSION` file and `Dockerfile`.
+- The image for cross compiling in [build-tools/build-image/cross/](../../build-tools/build-image/cross/). The `VERSION` file and `Dockerfile`.
 - Update [dockerized-e2e-runner.sh](https://github.com/kubernetes/test-infra/blob/master/jenkins/dockerized-e2e-runner.sh) to run a kubekins-e2e with the desired go version, which requires pushing [e2e-image](https://github.com/kubernetes/test-infra/tree/master/jenkins/e2e-image) and [test-image](https://github.com/kubernetes/test-infra/tree/master/jenkins/test-image) images that are `FROM` the desired go version.
 - The docker image being run in [hack/jenkins/gotest-dockerized.sh](../../hack/jenkins/gotest-dockerized.sh).
-- The cross tag `KUBE_BUILD_IMAGE_CROSS_TAG` in [build/common.sh](../../build/common.sh)
+- The cross tag `KUBE_BUILD_IMAGE_CROSS_TAG` in [build-tools/common.sh](../../build-tools/common.sh)
 
 ## Workflow
 

docs/devel/e2e-tests.md

@@ -305,7 +305,7 @@ Next, specify the docker repository where your ci images will be pushed.
 * Push the federation container images
 
   ```sh
-  $ build/push-federation-images.sh
+  $ build-tools/push-federation-images.sh
   ```
 
 #### Deploy federation control plane

docs/devel/running-locally.md

@@ -195,7 +195,7 @@ KUBE_DNS_DOMAIN="cluster.local"
 KUBE_DNS_REPLICAS=1
 ```
 
-To know more on DNS service you can look [here](http://issue.k8s.io/6667). Related documents can be found [here](../../build/kube-dns/#how-do-i-configure-it)
+To know more on DNS service you can look [here](http://issue.k8s.io/6667). Related documents can be found [here](../../build-tools/kube-dns/#how-do-i-configure-it)
 
 
 <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->

docs/proposals/multi-platform.md

@@ -311,7 +311,7 @@ A great blog post [that is describing this](https://medium.com/@rakyll/go-1-5-cr
 Before Go 1.5, the whole Go project had to be cross-compiled from source for **all** platforms that _might_ be used, and that was quite a slow process:
 
 ```console
-# From build/build-image/cross/Dockerfile when we used Go 1.4
+# From build-tools/build-image/cross/Dockerfile when we used Go 1.4
 $ cd /usr/src/go/src
 $ for platform in ${PLATFORMS}; do GOOS=${platform%/*} GOARCH=${platform##*/} ./make.bash --no-clean; done
 ```
@@ -322,7 +322,7 @@ If you cross-compile multiple times, Go will build parts of `std`, throw it away
 However, there is an easy way of cross-compiling all `std` packages in advance with Go 1.5+:
 
 ```console
-# From build/build-image/cross/Dockerfile when we're using Go 1.5+
+# From build-tools/build-image/cross/Dockerfile when we're using Go 1.5+
 $ for platform in ${PLATFORMS}; do GOOS=${platform%/*} GOARCH=${platform##*/} go install std; done
 ```
 
@@ -411,7 +411,7 @@ In order to dynamically compile a go binary with `cgo`, we need `gcc` installed
 
 The only Kubernetes binary that is using C code is the `kubelet`, or in fact `cAdvisor` on which `kubelet` depends. `hyperkube` is also dynamically linked as long as `kubelet` is. We should aim to make `kubelet` statically linked.
 
-The normal `x86_64-linux-gnu` can't cross-compile binaries, so we have to install gcc cross-compilers for every platform. We do this in the [`kube-cross`](../../build/build-image/cross/Dockerfile) image,
+The normal `x86_64-linux-gnu` can't cross-compile binaries, so we have to install gcc cross-compilers for every platform. We do this in the [`kube-cross`](../../build-tools/build-image/cross/Dockerfile) image,
 and depend on the [`emdebian.org` repository](https://wiki.debian.org/CrossToolchains). Depending on `emdebian` isn't ideal, so we should consider using the latest `gcc` cross-compiler packages from the `ubuntu` main repositories in the future.
 
 Here's an example when cross-compiling plain C code: