DockerCLI/dockerfiles/Dockerfile.cross

ARG GO_VERSION=1.13.15

FROM	dockercore/golang-cross:${GO_VERSION}
ENV     DISABLE_WARN_OUTSIDE_CONTAINER=1
WORKDIR /go/src/github.com/docker/cli
COPY    . .
Bump Golang 1.13.15 full diff: https://github.com/golang/go/compare/go1.13.14...go1.13.15 go1.13.15 (released 2020/08/06) includes security fixes to the encoding/binary package. See the Go 1.13.15 milestone on the issue tracker for details. https://github.com/golang/go/issues?q=milestone%3AGo1.13.15+label%3ACherryPickApproved Signed-off-by: Sebastiaan van Stijn <github@gone.nl> 2020-08-10 11:24:48 -04:00			`ARG GO_VERSION=1.13.15`
Dockerfile: use GO_VERSION build-arg for overriding Go version This allows overriding the version of Go without making modifications in the source code, which can be useful to test against multiple versions. For example: make GO_VERSION=1.13beta1 -f docker.Makefile binary Signed-off-by: Sebastiaan van Stijn <github@gone.nl> 2019-07-18 05:13:45 -04:00
			`FROM dockercore/golang-cross:${GO_VERSION}`
Set DISABLE_WARN_OUTSIDE_CONTAINER in the Dockerfile so that we don't spend 10s sleeping in CI also add time to validate check Signed-off-by: Daniel Nephin <dnephin@docker.com> 2017-08-15 14:32:44 -04:00			`ENV DISABLE_WARN_OUTSIDE_CONTAINER=1`
Support building a dynbinary Cleanup dynbinary and binary builds Signed-off-by: Daniel Nephin <dnephin@docker.com> 2017-05-11 18:52:17 -04:00			`WORKDIR /go/src/github.com/docker/cli`
Do not patch Dockerfiles in CI When building the Dockerfiles for development, those images are mainly used to create a reproducible build-environment. The source code is bind-mounted into the image at runtime; there is no need to create an image with the actual source code, and copying the source code into the image would lead to a new image being created for each code-change (possibly leading up to many "dangling" images for previous code-changes). However, when building (and using) the development images in CI, bind-mounting is not an option, because the daemon is running remotely. To make this work, the circle-ci script patched the Dockerfiles when CI is run; adding a `COPY` to the respective Dockerfiles. Patching Dockerfiles is not really a "best practice" and, even though the source code does not and up in the image, the source would still be _sent_ to the daemon for each build (unless BuildKit is used). This patch updates the makefiles, circle-ci script, and Dockerfiles; - When building the Dockerfiles locally, pipe the Dockerfile through stdin. Doing so, prevents the build-context from being sent to the daemon. This speeds up the build, and doesn't fill up the Docker "temp" directory with content that's not used - Now that no content is sent, add the COPY instructions to the Dockerfiles, and remove the code in the circle-ci script to "live patch" the Dockerfiles. Before this patch is applied (with cache): ``` $ time make -f docker.Makefile build_shell_validate_image docker build -t docker-cli-shell-validate -f ./dockerfiles/Dockerfile.shellcheck . Sending build context to Docker daemon 41MB Step 1/2 : FROM debian:stretch-slim ... Successfully built 81e14e8ad856 Successfully tagged docker-cli-shell-validate:latest 2.75 real 0.45 user 0.56 sys ``` After this patch is applied (with cache):: ``` $ time make -f docker.Makefile build_shell_validate_image cat ./dockerfiles/Dockerfile.shellcheck \| docker build -t docker-cli-shell-validate - Sending build context to Docker daemon 2.048kB Step 1/2 : FROM debian:stretch-slim ... Successfully built 81e14e8ad856 Successfully tagged docker-cli-shell-validate:latest 0.33 real 0.07 user 0.08 sys ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl> 2018-11-28 19:06:10 -05:00			`COPY . .`