Old selector was wrong (it watched for the label we applied to child
resources when reconciling the stack, instead of the stack itself)
This should be back-ported to older version of the CLI
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
(cherry picked from commit 8cd74eb33a)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: f89d05edcb
Component: cli
This patch switches the shellcheck image to use the official image
from Docker Hub.
Note that this does not yet update shellcheck to the latest version (v0.5.x);
Shellcheck v0.4.7 added some new checks, which makes CI currently fail, so will
be done in a follow-up PR. Instead, the v0.4.6 version is used in this PR, which
is closest to the same version as was installed in the image before this change;
```
docker run --rm docker-cli-shell-validate shellcheck --version
ShellCheck - shell script analysis tool
version: 0.4.4
license: GNU General Public License, version 3
website: http://www.shellcheck.net
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 388646eab0)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: b59752479b
Component: cli
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>
(cherry picked from commit 166856ab1b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 8997667aa2
Component: cli
When manually stopping a container with a restart-policy, the container
would show as "restarting" in `docker ps` whereas its actual state
is "exited".
Stopping a container with a restart policy shows the container as "restarting"
docker run -d --name test --restart unless-stopped busybox false
docker stop test
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7e07409fa1d3 busybox "false" 5 minutes ago Restarting (1) 4 minutes ago test
However, inspecting the same container shows that it's exited:
docker inspect test --format '{{ json .State }}'
{
"Status": "exited",
"Running": false,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 0,
"ExitCode": 1,
"Error": "",
"StartedAt": "2019-02-14T13:26:27.6091648Z",
"FinishedAt": "2019-02-14T13:26:27.689427Z"
}
And killing the container confirms this;
docker kill test
Error response from daemon: Cannot kill container: test: Container 7e07409fa1d36dc8d8cb8f25cf12ee1168ad9040183b85fafa73ee2c1fcf9361 is not running
docker run -d --name test --restart unless-stopped busybox false
docker stop test
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d0595237054a busybox "false" 5 minutes ago Restarting (1) 4 minutes ago exit
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 8c0ecb638705e89746a81fa1320aafaa7ff701b2)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 00f0b9df0dde80b2c40023b12a29dd476f2a77e2
Component: engine
When running a container in the host's network namespace, the container
gets a copy of the host's resolv.conf (copied to `/etc/resolv.conf` inside
the container).
The current code always used the default (`/etc/resolv.conf`) path on the
host, irregardless if `systemd-resolved` was used or not.
This patch uses the correct file if `systemd-resolved` was detected
to be running.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 8364d1c9d590d4266871cd820b76ef12e2b934ed)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 04ae160eca4a8bc134ca9abafa044191b893080b
Component: engine
The integration test TestExportContainerWithOutputAndImportImage in moby/moby is the same as TestExportContainerAndImportImage,
except for the output file option. Adding a unit test to cover the output file option of the export command here allows
the removal of the redundant integration test TestExportContainerWithOutputAndImportImage.
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
(cherry picked from commit fc1e11d46a)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 079adf3f23
Component: cli
Tagger was not called for BuildKit-mode.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
(cherry picked from commit 7fc0f820ea1e9036a1466ee8ef7a7395b792623f)
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
Upstream-commit: 8d87a2a4bc88b235f06e3995bb33f978d7c28cdf
Component: engine
Signed-off-by: John Howard <jhoward@microsoft.com>
Signed-off-by: Tibor Vass <tibor@docker.com>
(cherry picked from commit 9d2e97ac6e20b17477947fc63e70299938606a38)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 91703956dffcf1d9c997aea83f9489a8c768412d
Component: engine
Signed-off-by: John Howard <jhoward@microsoft.com>
(cherry picked from commit 80fce6d747c5208b42e94ac9e3f22cef28dd8afe)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: fd4670161de8f9947c524138c477177f935c98f2
Component: engine
There's little way of knowing what each exit status means at present
because it's not documented. I'm assuming they are the same as docker
run.
Signed-off-by: Eric Curtin <ericcurtin17@gmail.com>
(cherry picked from commit 23670968cc)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 27ab7cc3d6
Component: cli
