As described in #100596 this can surprise newcomers.
This adds a paragraph which explains where are the build
artifacts are and how to use the docker images produced
by the build system.
docker buildx CLI plugin is not default enable most functionality which we
comsumed during build releases. Means `docker buildx build` will work, but
flags like `--load` or `--platform` is not supported. Which is still true
statement with most up-to-date docker version. That means for new join
member who plan to build by themself, will need to notice if buildx is
properly installed. And not getting confused by build script when docker
complant about unknown flag `--load`, `--platoform`. Hance, add buildx
instruction to note.
As discussed in https://github.com/kubernetes/kubernetes/issues/11852#issuecomment-387868165
We need at least 8 GB RAM assigned to Docker for Mac. Otherwise
the build will likely fail.
Bumping this requirement saves time people who assigns 4.5 GB
RAM and fails.
Signed-off-by: Robin Cernin <cerninr@gmail.com>
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Add documentation around build reproducibility and SOURCE_DATE_EPOCH
**What this PR does / why we need it**: makes some of our notes about reproducibility a bit more discoverable.
**Release note**:
```release-note
NONE
```
/assign @BenTheElder
Mac OS X was renamed to OS X in 2012, and then renamed again to macOS in 2016.
I suggest that the current name should be used when referencing the Apple OS.
We also add "version" to all docker images and containers
This version is to be incremented manually when we change the shape of the build
image (like changing the golang version or the set of volumes in the data
container). This will delete all older versions of images and containers when
the version is different.
This fix updates the build docs to include the path of `build/` for
shell scripts. The reason is that while trying to follow the `build/README.md`,
it is not obvious that all the scripts, e.g., `run.sh make`, `shell.sh`,
etc. needs to be executed from the root directory (vs. executed from the
`build/` directory). In other words,
the executation should be:
```
build/run.sh make
build/make-clean.sh
...
```
This fix adds `build/` so that it is easy for user to follow the steps.
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.
* 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.
