Also move c.Lock() below containerd delete task, as it doesn't seem that
there is any necessity to hold the container lock while containerd is
killing the task.
This fixes a potential edge-case where containerd delete task hangs, and
thereafter all operations on the container would hang forever, as this
function is holding onto the container lock.
Signed-off-by: Cam <gh@sparr.email>
This old test is failing after an edge-case change in dockerfile
parsing considered a bugfix: https://github.com/moby/buildkit/pull/1559
Instead of fixing the test, I suggest removing it as there are already
tests for it in BuildKit.
Signed-off-by: Tibor Vass <tibor@docker.com>
The image that's built is not pushed anywhere, and is just
building the same as the main image already builds, so didn't
add value.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
libcontainer does not guarantee a stable API, and is not intended
for external consumers.
this patch replaces some uses of libcontainer/cgroups with
containerd/cgroups.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Rather than bifurcate the test completely, this lets us keep the test
intact with a small function wrapper to allow the compiler to build the
code that'll never be called on Windows, on Windows.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
It turns out that the Finally block does not see the exit code from the
`exit` call that triggered it, but from an earlier state. And it seems
that actions take in the Finally block other than `exit` will not affect
the $LastErrorCode set by the `exit` that triggered the Finally block.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Commit 6ca3ec88ae deprecated the experimental
"--stream" option for the legacy builder, adding an error message is a client
attempted to use this feature.
However, the detection used the session-ID (`session=xxx` query parameter),
which happens to be set automatically by the CLI if it detects that the daemon
has session support. Because of this, builds fail when trying to perform them
on a daemon with the `--experimental` flag set.
This patch changes the detection to look for the `remote` query parameter, which
is set to "client-session" when using the `--stream` option with the classic
(non-Buildkit) builder.
Before this change, running `docker build` with an older (19.03 or older) cli
against a daemon with `--experimental` enabled caused an error:
$ dockerd --experimental &
$ docker pull docker:18.09
$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock docker:18.09 sh -c 'echo "FROM scratch" | docker build -'
Sending build context to Docker daemon 2.048kB
Error response from daemon: experimental session with v1 builder is no longer supported, use builder version v2 (BuildKit) instead
docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -w /foo docker:18.09 sh -c 'echo "FROM scratch" > Dockerfile && docker build --stream .'
Error response from daemon: experimental session with v1 builder is no longer supported, use builder version v2 (BuildKit) instead
With this patch, the error only occurs when trying to use the experimental
`--stream` option:
$ dockerd --experimental &
$ docker pull docker:18.09
$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock docker:18.09 sh -c 'echo "FROM scratch" | docker build -'
Step 1/1 : FROM scratch
--->
No image was generated. Is your Dockerfile empty?
$ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -w /foo docker:18.09 sh -c 'echo "FROM scratch" > Dockerfile && docker build --stream .'
Error response from daemon: experimental session with v1 builder is no longer supported, use builder version v2 (BuildKit) instead
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We aren't using containerd's image store, so we shouldn't be setting
this value.
This fixes container checkpoints, where containerd attempts to
checkpoint the image since one is set, but the image does not exist in
containerd.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
The daemon expects to manage/handle everything going into the containerd namespace it uses, and things break when it shares that namespace with a second instance, so we should expose these flags and expect users that want two daemons sharing a containerd instance to use separate namespaces for them.
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
This allows us to cache manifests and avoid extra round trips to the
registry for content we already know about.
dockerd currently does not support containerd on Windows, so this does
not store manifests on Windows, yet.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
