Rework hack/ and build/ directories.

* Rewrite a bunch of the hack/ directory with modular reusable bash libraries.
* Have 'build/*' build on 'hack/*'.  The stuff in build now just runs hack/* in a docker container.
* Use a docker data container to enable faster incremental builds.
* Standardize output to _output/{local,dockerized}/bin/OS/ARCH/*.  This regularized placement makes cross compilation work.
* Move travis specific scripts under hack/travis

With new dockerized incremental builds, I can do a no-op `make quick-release` in ~30s.  This is a significant improvement.
This commit is contained in:
Joe Beda
2014-10-22 16:26:59 -07:00
parent 203a3d0cec
commit 5d33ce46cc
51 changed files with 1005 additions and 789 deletions

View File

@@ -18,12 +18,13 @@ There is also early support for building Docker "run" containers
## Key scripts
* `make-server.sh`: This will compile all of the Kubernetes server binaries for linux/amd64
* `make-client.sh`: This will make all cross-compiled client binaries
* `run-tests.sh`: This will run the Kubernetes unit tests
* `run-integration.sh`: This will build and run the integration test
* `copy-output.sh`: This will copy the contents of `_output/build` from any remote Docker container to the local `_output/build`. Right now this is only necessary on Mac OS X with `boot2docker`.
* `make-clean.sh`: Clean out the contents of `_output/build` and remove any local built container images.
* `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 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
* `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.
* `release.sh`: Build everything, test it, and (optionally) upload the results to a GCS bucket.
@@ -81,10 +82,10 @@ If the release script is set to upload to GCS, it'll do the following:
These are in no particular order
* [ ] Harmonize with scripts in `hack/`. How much do we support building outside of Docker and these scripts?
* [X] Harmonize with scripts in `hack/`. How much do we support building outside of Docker and these scripts?
* [ ] Get a cluster up and running with the Docker images. Perhaps start with a local cluster and move up to a GCE cluster.
* [ ] Implement (#186)[https://github.com/GoogleCloudPlatform/kubernetes/issues/186]. This will make it easier to develop Kubernetes.
* [ ] Deprecate/replace most of the stuff in the hack/
* [X] Deprecate/replace most of the stuff in the hack/
* [ ] Create an install script that'll let us do a `curl https://[URL] | bash` to get that tarball down and ensure that other dependencies (cloud SDK?) are installed and configured correctly.
* [ ] Support/test Windows as a client.
* [ ] Finish support for the Dockerized runtime. Issue (#19)[https://github.com/GoogleCloudPlatform/kubernetes/issues/19]. A key issue here is to make this fast/light enough that we can use it for development workflows.