This allows us to run CI with the containerd snapshotter enabled, without
patching the daemon.json, or changing how tests set up daemon flags.
A warning log is added during startup, to inform if this variable is set,
as it should only be used for our integration tests.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
release notes: https://github.com/docker/buildx/releases/tag/v0.8.2
Notable changes:
- Update Compose spec used by buildx bake to v1.2.1 to fix parsing ports definition
- Fix possible crash on handling progress streams from BuildKit v0.10
- Fix parsing groups in buildx bake when already loaded by a parent group
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker 17.07 and up allow the CLI to be configured to set default proxy
env-vars to be used (both as build-arg and as env for docker run), see
docker/cli#93, so setting these here should be redundant. If someone
needs these env-vars set, they should be configured in the cli's
`~/.docker/config.json` instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When building the dev image, the Makefile generates a tag-name for the image,
based on the current git branch. As a result of this naming, old images will
collect on a developer's machine (especially when building from different
branches, for example when reviewing pull requests):
REPOSITORY TAG IMAGE ID CREATED SIZE
docker-dev HEAD 9785a8fb82f5 30 hours ago 2.13GB
docker-dev master 9785a8fb82f5 30 hours ago 2.13GB
docker-dev seccomp-closer-to-oci 9785a8fb82f5 30 hours ago 2.13GB
docker-dev move-stackdump 06882c142bfd 2 days ago 2.13GB
docker-dev add-dns-to-docker-info 2961ed1b99bd 10 days ago 2.13GB
docker-dev add-platform-info 2961ed1b99bd 10 days ago 2.13GB
docker-dev rata-seccomp-new-fields 2961ed1b99bd 10 days ago 2.13GB
docker-dev swagger-wip 2961ed1b99bd 10 days ago 2.13GB
docker-dev system-df-types 2961ed1b99bd 10 days ago 2.13GB
docker-dev use-oci-platform 2961ed1b99bd 10 days ago 2.13GB
docker-dev update-swagger-fork 3eeedecca85a 2 weeks ago 2.13GB
docker-dev remove-lcow-step5-alternative 51f9720bbc19 2 weeks ago 2.13GB
docker-dev update-s390x-ubuntu-2004 51f9720bbc19 2 weeks ago 2.13GB
docker-dev fix-image-shared-size 09e9aa46694a 2 weeks ago 2.13GB
docker-dev remove-discovery 11823223ae83 3 weeks ago 2.13GB
docker-dev daemon-config 355643e371b0 4 weeks ago 2.12GB
docker-dev jenkins-windows-containerd 68199214b860 4 weeks ago 2.11GB
docker-dev unfork-buildkit 68199214b860 4 weeks ago 2.11GB
docker-dev warn-on-non-matching-platform bc014b94017f 5 weeks ago 2.11GB
docker-dev remove-lcow 3a43c0900282 6 weeks ago 2.11GB
docker-dev remove-lcow-part5 3a43c0900282 6 weeks ago 2.11GB
docker-dev remove-lcow-step3 3a43c0900282 6 weeks ago 2.11GB
docker-dev remove-lcow-step4 3a43c0900282 6 weeks ago 2.11GB
docker-dev seccomp-unconfined-daemon 3a43c0900282 6 weeks ago 2.11GB
docker-dev update-authors 3a43c0900282 6 weeks ago 2.11GB
docker-dev payall4u-fix-creating-sandbox-when-disable-bridge 114c0f2ceb17 6 weeks ago 2.12GB
docker-dev catch-almost-all f437d2bc512b 8 weeks ago 2.12GB
docker-dev bin-criu c72894ae66f3 2 months ago 2.12GB
docker-dev bump-golang-1-14 395932141809 2 months ago 2.14GB
docker-dev upstream-systemd-units d0cb07f9473c 2 months ago 2.12GB
docker-dev bump-criu 6ed9e8fcf59f 2 months ago 2.12GB
This images are a bit of a pain to clean up, and because they are tagged,
`docker image prune` or `docker system prune` doesn't help (unless `--all` is
used).
Looking at the background of this naming, a found that it was originally added
in a95712899e, after a discussion on PR 3471.
At the time, the image name was used to check if the image needed building, and
otherwise building was skipped in the makefile.
This is no longer the case; the image is built unconditionally, and the build-
cache helps (where possible) speed up rebuilding the image.
In _theory_ having unique names would allow for multiple dev containers (from
different branches) to be started in parallel, but in most situations, the
source-code will be mounted (`BIND_MOUNT=.`), so I'm not sure if that should
be a compelling reason to keep the current naming.
This patch removes the unique tag, and will always tag the image locally as
`docker-dev:latest`.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was originally added in 833444c0d6,
at which time buildx did not yet have a release, so we had to build
from source.
Now that buildx has binary releases on GitHub, we should be able to
consume those binaries instead of building.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The empty `binary:`, `dynbinary:`, and `cross:` targets at the top were
only useful to provide the description for `make help`.
This patch splits the actual `binary`, `dynbinary`, and `cross` targets
to separate lines, introducing some slight duplicated code, but making
it slightly easier to read (and removing the "empty" targets).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These two targets seem interchangeable, just that the old `build` target
always built the `final` Dockerfile target even if the source was going
to be bind mounted anyway.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Windows still writes to the autogen directory, but the source code is
mounted in as read-only.
In order to do enable this without taking a massive hit in doing an rw
mount (for the source code) we mount a tmpfs into the build at the
autogen dir.
In order for this to work the directory must alreay exist, so we create
it before entering the build.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This introduces a FORCE_VALIDATE environment variable, which allows
forcing some validation steps, even if no changes were detected.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The binary targets now use buildkit to build/output binaries instead of
doing it in a DOCKER_RUN_DOCKER container. With that change caused
issues when trying to call multiple make targets such as `make binary
cross` since those targets are updating the variables (with conflicting
data) used by the shared `build` prerequisite.
This change has those binary output targets call `docker build` (or
`buildx build`) directly since that is the action they are preforming
and no longer have any pre-reqs.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Un-indent the comment, so that it doesn't get printed by
the shell script (moved it above the target, as it looked
slightly less cluttered)
Also fixed the "help" comment, so that it shows up in
`make help`, and removed the un-needed dummy `buildx:` target.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This simplifies the makefile a bit, while preserving
the functionality. Using a non-existing Dockerfile
to demonstrate:
make buildx
Successfully tagged moby-buildx:latest
92059305df7371f8b5b3638d4d405d49ff909031a7bc6d2f515cb0a0df03c2f4
github.com/docker/buildx v0.3.0 c967f1d
make BUILDX_DOCKERFILE=foo buildx
BUILDX_DOCKERFILE=foo buildx
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /Users/sebastiaan/go/src/github.com/docker/docker/foo: no such file or directory
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch removes the `BUILDX_COMMIT` make variable. With the
make variable removed, it no longer "masks" environment variables,
and there is no longer a need to export the variable.
A side effect of this change, is that (by default), the buildx
image is tagged as `moby-buildx:latest`. This likely isn't a
problem, because the build-cache would still be preserved in
intermediate images. Having the image tagged as `:latest` also
makes cleaning up easier (without having to remove the image
for each version tagged.
Otherwise, the behavior remains the same as before:
# default
rm -f bundles/buildx && make buildx
# => => naming to docker.io/library/moby-buildx:latest
github.com/docker/buildx v0.3.0 c967f1d
# using a make variable:
rm -f bundles/buildx && make BUILDX_COMMIT=v0.2.1 buildx
# => => naming to docker.io/library/moby-buildx:v0.2.1
github.com/docker/buildx v0.2.1 0eb2df5
# using an environment variable:
rm -f bundles/buildx && BUILDX_COMMIT=v0.2.2 make buildx
# => => naming to docker.io/library/moby-buildx:v0.2.2
github.com/docker/buildx v0.2.2 ab5fe3d
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `BUILDX_COMMIT` variable was set as a Make variable,
which isn't exported, and thus not available in scripts,
unless referenced through `$(VAR)` (non-curly-brackets).
As a result `--build-arg BUILDX_COMMIT` did not set the
`BUILDX_COMMIT` build-arg, and the default from the Dockerfile
(`master`) was used instead.
This patch exports the default version that's set in the
Makefile, so that it can be used as a regular environment
variable. The script was also slighly modified to no longer
use the `Make` variable.
In addition, the `buildx` target now calls `buildx version`,
which is useful to confirm if the binary was successfully built
(and with the correct version).
Before:
rm -f bundles/buildx && make buildx && ./bundles/buildx version
# => => naming to docker.io/library/moby-buildx:v0.3.0
github.com/docker/buildx v0.3.1 6db68d0
# using a make variable:
rm -f bundles/buildx && make BUILDX_COMMIT=v0.2.1 buildx && ./bundles/buildx version
# => => naming to docker.io/library/moby-buildx:v0.2.1
github.com/docker/buildx v0.3.1 6db68d0
# using an environment variable:
rm -f bundles/buildx && BUILDX_COMMIT=v0.2.2 make buildx && ./bundles/buildx version
# => => naming to docker.io/library/moby-buildx:v0.2.2
github.com/docker/buildx v0.3.1 6db68d0
After:
# default
rm -f bundles/buildx && make buildx
# => => naming to docker.io/library/moby-buildx:v0.3.0
github.com/docker/buildx v0.3.0 c967f1d
# using a make variable:
rm -f bundles/buildx && make BUILDX_COMMIT=v0.2.1 buildx
# => => naming to docker.io/library/moby-buildx:v0.2.1
github.com/docker/buildx v0.2.1 0eb2df5
# using an environment variable:
rm -f bundles/buildx && BUILDX_COMMIT=v0.2.2 make buildx
# => => naming to docker.io/library/moby-buildx:v0.2.2
github.com/docker/buildx v0.2.2 ab5fe3d
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was inadvertently removed when updating the Dockerfile for buildkit
specific features.
Trick selects a different build target depending on if the source is
going to be bind-mounted in anyway, which prevents the need to copy the
whole source tree to the builder.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Since the dockerfile now requires buildkit, let's just use buildx can
bootstrap itself into even an old version of Docker which does not
support buildkit.
This also decouples the Dockerfile/build from the version of Docker
which is installed.
One major downside:
If buildx needs to setup a container driver (ie, docker does not support
buildkit), the `make shell` target (and others which call
`DOCKER_RUN_DOCKER`) must export the image from buildkit and into
docker. This added an extra 70s to a full build for me (agan only for targets
which call `DOCKER_RUN_DOCKER`) and 40s on a rebuild (with no changes).
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
'Namespace' parallel runs by bind-mounting a different directory
in the container, instead of making the tests running inside
the container aware of the namespaced location.
This makes it transparent to the tests, and slightly reduces
complexity.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is basically taking some stuff that make a custom shell function
for.
This takes a test filter, builds the appropriate TESTFLAGS, and sets the
integration API test dirs that match the given filter to avoid building
all test dirs.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
1. Use `go list` to get list of integration dirs to build. This means we
do not need to have a valid `.go` in every subdirectory and also
filters out other dirs like "bundles" which may have been created.
2. Add option to specify custom flags for integration and
integration-cli. This is needed so both suites can be run AND set
custom flags... since the cli suite does not support standard go
flags.
3. Add options to skip an entire integration suite.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
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 shell
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adds `DOCKER_BINDDIR_MOUNT_OPTS` to easily tweak the BINDDIR mount
options... primarily adding so I can control the caching mode for
osxfs because compiling takes > 1min for me with the default and < 30s
with both `cached` and `delegated`.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
integration-on-swarm had unnecessary complexity and was too hard to
maintain. Also, it didn't support the new non-CLI integration test suite.
I'm now doing some experiments out of the repo using Kubernetes:
https://github.com/AkihiroSuda/kube-moby-integration
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Not exactly sure why, but this line;
build: DOCKER_CROSS ?= false
Always overwrote `DOCKER_CROSS` when running `make cross`.
Perhaps because it is set in `cross: DOCKER_CROSS := true`,
and in a different scope? May also be dependent on the
version of `make` in use.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Pretty much cross-compile doesn't work because of this:
> profiles/seccomp/seccomp.go:13:2: build constraints exclude all Go files in /go/src/github.com/docker/docker/vendor/github.com/seccomp/libseccomp-golang
This changes adds a new Dockerfile target for cross compilation with the
neccesary arch specific libseccomp packages and CC toolchains.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Instead of having to go through files or registry values as is currently the
case.
While adding GMSA support to Kubernetes (https://github.com/kubernetes/kubernetes/pull/73726)
I stumbled upon the fact that Docker currently only allows passing Windows
credential specs through files or registry values, forcing the Kubelet
to perform a rather awkward dance of writing-then-deleting to either the
disk or the registry to be able to create a Windows container with cred
specs.
This patch solves this problem by making it possible to directly pass
whole base64-encoded cred specs to the engine's API. I took the opportunity
to slightly refactor the method responsible for Windows cred spec as it
seemed hard to read to me.
Added some unit tests on Windows credential specs handling, as there were
previously none.
Added/amended the relevant integration tests.
I have also tested it manually: given a Windows container using a cred spec
that you would normally start with e.g.
```powershell
docker run --rm --security-opt "credentialspec=file://win.json" mcr.microsoft.com/windows/servercore:ltsc2019 nltest /parentdomain
# output:
# my.ad.domain.com. (1)
# The command completed successfully
```
can now equivalently be started with
```powershell
$rawCredSpec = & cat 'C:\ProgramData\docker\credentialspecs\win.json'
$escaped = $rawCredSpec.Replace('"', '\"')
docker run --rm --security-opt "credentialspec=raw://$escaped" mcr.microsoft.com/windows/servercore:ltsc2019 nltest /parentdomain
# same output!
```
I'll do another PR on Swarmkit after this is merged to allow services to use
the same option.
(It's worth noting that @dperny faced the same problem adding GMSA support
to Swarmkit, to which he came up with an interesting solution - see
https://github.com/moby/moby/pull/38632 - but alas these tricks are not
available to the Kubelet.)
Signed-off-by: Jean Rouge <rougej+github@gmail.com>
CIs are assumed to do a git fetch and git merge before running tests.
Therefore, no need for a git fetch inside our validate scripts in CI.
If VALIDATE_ORIGIN_BRANCH is set, then git fetch is skipped and
VALIDATE_ORIGIN_BRANCH is used in validate scripts.
Otherwise, behavior is unchanged.
Signed-off-by: Tibor Vass <tibor@docker.com>
