I was in the process of cleaning up some error-messages, and it looks like
the docker-py tests were depending on strings that will be removed;
=================================== FAILURES ===================================
_____________ CreateContainerTest.test_create_with_restart_policy ______________
tests/integration/api_container_test.py:126: in test_create_with_restart_policy
assert 'You cannot remove ' in err
E AssertionError: assert 'You cannot remove ' in 'cannot remove container d11580f6078108691096ec8a23404a6bda9ad1d1b2bafe88b17d127a67728833: container is restarting: stop the container before removing or force remove'
____________________ ErrorsTest.test_api_error_parses_json _____________________
tests/integration/errors_test.py:13: in test_api_error_parses_json
assert 'You cannot remove a running container' in explanation
E AssertionError: assert 'You cannot remove a running container' in 'cannot remove container 4b90ce2e907dd0f99d0f561619b803e7a2a31809ced366c537874dd13f8a47ec: container is running: stop the container before removing or force remove'
This updates the tests to match on a string that will be present in both the
old and new error-messages, but added a "lower()", so that matching will be
done case-insensitive (Go errors generally should be lowercase).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Run flake8 docker/ tests/
flake8 docker/ tests/
shell: /usr/bin/bash -e {0}
env:
DOCKER_BUILDKIT: 1
pythonLocation: /opt/hostedtoolcache/Python/3.11.4/x64
PKG_CONFIG_PATH: /opt/hostedtoolcache/Python/3.11.4/x64/lib/pkgconfig
Python_ROOT_DIR: /opt/hostedtoolcache/Python/3.11.4/x64
Python2_ROOT_DIR: /opt/hostedtoolcache/Python/3.11.4/x64
Python3_ROOT_DIR: /opt/hostedtoolcache/Python/3.11.4/x64
LD_LIBRARY_PATH: /opt/hostedtoolcache/Python/3.11.4/x64/lib
tests/integration/api_container_test.py:1395:16: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
tests/integration/api_container_test.py:1408:24: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
tests/integration/api_image_test.py:35:16: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
tests/integration/api_image_test.py:46:16: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
Error: Process completed with exit code 1.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is related to https://github.com/moby/moby/pull/44216
Prunes will, by default, no longer prune named volumes, only anonymous ones.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
While removing any usage of the deprecated `distutils` package,
("The distutils package is deprecated and slated for removal in Python 3.12.")
this internal utility can be removed straightaway because the
`shutil.which` replacement for `distutils.spawn.find_executable`
already honors the `PATHEXT` environment variable in windows systems.
See https://docs.python.org/3/library/shutil.html#shutil.which
Signed-off-by: Daniel Möller <n1ngu@riseup.net>
`rollback_config` was not in the list of `CREATE_SERVICE_KWARGS`
which prevented it from being an argument when creating services.
It has now been added and the problem fixed, allowing services to
have a rollback_config during creation and updating.
Fixes#2832.
Signed-off-by: Fraser Patten <pattenf00@gmail.com>
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Co-authored-by: Milas Bowman <milas.bowman@docker.com>
* Upgrade websocket-client to latest
* Add basic integration test for streaming logs via websocket
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Set `daemon` attribute instead of using `setDaemon` method that
was deprecated in Python 3.10.
Signed-off-by: Karthikeyan Singaravelan <tir.karthi@gmail.com>
This test looks for some behavior on non-chunked HTTP requests.
It now fails because it looks like recent versions of Docker Engine
ALWAYS return chunked responses (or perhaps this specific response
changed somehow to now trigger chunking whereas it did not previously).
The actual logic it's trying to test is also unusual because it's
trying to hackily propagate errors under the assumption that it'd get
a non-chunked response on failure, which is...not reliable. Arguably,
the chunked reader should be refactored somehow but that's a refactor
we can't really commit to (and it's evidently been ok enough as is
up until now).
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Ensure the container has exited before attempting to grab the logs.
Since we are not streaming them, it's possible to attach + grab logs
before the output is processed, resulting in a test failure. If the
container has exited, it's guaranteed to have logged :)
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
This test was verifying that the container has the right options set (through
`docker inspect`), but also checks if the cgroup-rules are set within the
container by reading `/sys/fs/cgroup/devices/devices.list`
Unlike cgroups v1, on cgroups v2, there is no file interface, and rules are
handled through ebpf, which means that the test will fail because this file
is not present.
From the Linux documentation for cgroups v2:
https://github.com/torvalds/linux/blob/v5.16/Documentation/admin-guide/cgroup-v2.rst#device-controller
> (...)
> Device controller manages access to device files. It includes both creation of
> new device files (using mknod), and access to the existing device files.
>
> Cgroup v2 device controller has no interface files and is implemented on top
> of cgroup BPF. To control access to device files, a user may create bpf programs
> of type BPF_PROG_TYPE_CGROUP_DEVICE and attach them to cgroups with
> BPF_CGROUP_DEVICE flag. (...)
Given that setting the right cgroups is not really a responsibility of this SDK,
it should be sufficient to verify that the right options were set in the container
configuration, so this patch is removing the part that checks the cgroup, to
allow this test to be run on a host with cgroups v2 enabled.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
ContainerSpec
Docker Engine v1.41 added `CapAdd` and `CapDrop` as part of the
ContainerSpec, and `docker-py` should do the same.
```
GET /services now returns CapAdd and CapDrop as part of the ContainerSpec.
GET /services/{id} now returns CapAdd and CapDrop as part of the ContainerSpec.
POST /services/create now accepts CapAdd and CapDrop as part of the ContainerSpec.
POST /services/{id}/update now accepts CapAdd and CapDrop as part of the ContainerSpec.
GET /tasks now returns CapAdd and CapDrop as part of the ContainerSpec.
GET /tasks/{id} now returns CapAdd and CapDrop as part of the ContainerSpec.
```
I added capabilities on docstrings, `service.create` init method and
create tests for that.
That change was mention in issue #2802.
Signed-off-by: Felipe Ruhland <felipe.ruhland@gmail.com>
This test was updated in 7d92fbdee1, but
omitted the "error" prefix in the message, causing the test to fail;
_________ CreateContainerTest.test_invalid_log_driver_raises_exception _________
tests/integration/api_container_test.py:293: in test_invalid_log_driver_raises_exception
assert excinfo.value.explanation in expected_msgs
E AssertionError: assert 'error looking up logging plugin asdf: plugin "asdf" not found' in ["logger: no log driver named 'asdf' is registered", 'looking up logging plugin asdf: plugin "asdf" not found']
E + where 'error looking up logging plugin asdf: plugin "asdf" not found' = APIError(HTTPError('400 Client Error: Bad Request for url: http+docker://localhost/v1.39/containers/create')).explanation
E + where APIError(HTTPError('400 Client Error: Bad Request for url: http+docker://localhost/v1.39/containers/create')) = <ExceptionInfo APIError tblen=6>.value
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker API 1.32 added support for providing options to a network driver
via EndpointConfig when connecting a container to a network.
Signed-off-by: Mike Haboustak <haboustak@gmail.com>
The ImageCollectionTest.test_pull_multiple test performs a `docker pull` without
a `:tag` specified) to pull all tags of the given repository (image).
After pulling the image, the image(s) pulled are checked to verify if the list
of images contains the `:latest` tag.
However, the test assumes that all tags of the image are tags for the same
version of the image (same digest), and thus a *single* image is returned, which
is not always the case.
Currently, the `hello-world:latest` and `hello-world:linux` tags point to a
different digest, therefore the `client.images.pull()` returns multiple images:
one image for digest, making the test fail:
=================================== FAILURES ===================================
____________________ ImageCollectionTest.test_pull_multiple ____________________
tests/integration/models_images_test.py:90: in test_pull_multiple
assert len(images) == 1
E AssertionError: assert 2 == 1
E + where 2 = len([<Image: 'hello-world:linux'>, <Image: 'hello-world:latest'>])
This patch updates the test to not assume a single image is returned, and instead
loop through the list of images and check if any of the images contains the
`:latest` tag.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The BUSYBOX variable was renamed to TEST_IMG in
54b48a9b7a, however
0ddf428b6c got merged
after that change, but was out of date, and therefore
caused the tests to fail:
```
=================================== FAILURES ===================================
________ ServiceTest.test_create_service_with_network_attachment_config ________
tests/integration/api_service_test.py:379: in test_create_service_with_network_attachment_config
container_spec = docker.types.ContainerSpec(BUSYBOX, ['true'])
E NameError: global name 'BUSYBOX' is not defined
```
Fix the test by using the correct variable name.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These tests started failing on recent versions of the engine because the error string changed,
and due to a regression, the status code for one endpoint changed from a 400 to a 500.
On Docker 18.03:
The `docker build` case properly returns a 400, and "invalid platform" as error string;
```bash
docker build --platform=foobar -<<EOF
FROM busybox
EOF
Sending build context to Docker daemon 2.048kB
Error response from daemon: invalid platform: invalid platform os "foobar"
```
```
DEBU[2019-07-15T12:17:22.745511870Z] Calling GET /_ping
DEBU[2019-07-15T12:17:22.748224796Z] Calling POST /session
DEBU[2019-07-15T12:17:22.748692282Z] Calling POST /v1.37/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&labels=%7B%7D&memory=0&memswap=0&networkmode=default&platform=foobar&rm=1&session=d7b6ceba9d8d0aed67a805528554feb5285781fe888a4bf4e0c15cb09bffd614&shmsize=0&target=&ulimits=null
```
The `docker pull --platform=foobar hello-world:latest` case incorrectly returns a 500
```
DEBU[2019-07-15T12:16:08.744827612Z] Calling POST /v1.37/images/create?fromImage=hello-world&platform=foobar&tag=latest
DEBU[2019-07-15T12:16:08.745594874Z] FIXME: Got an API for which error does not match any expected type!!!: invalid platform: invalid platform os "foobar" error_type="*errors.errorString" module=api
ERRO[2019-07-15T12:16:08.745916686Z] Handler for POST /v1.37/images/create returned error: invalid platform: invalid platform os "foobar"
DEBU[2019-07-15T12:16:08.746191172Z] FIXME: Got an API for which error does not match any expected type!!!: invalid platform: invalid platform os "foobar" error_type="*errors.errorString" module=api
```
On Docker 18.09;
```bash
docker build --platform=foobar -<<EOF
FROM busybox
EOF
Error response from daemon: "foobar": unknown operating system or architecture: invalid argument
```
Which incorrectly returns a 500 status;
```
DEBU[2019-07-15T11:59:20.687268380Z] Calling POST /v1.39/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&labels=%7B%7D&memory=0&memswap=0&networkmode=default&platform=foobar&rm=1&session=jko7kejjvs93judyfnq7shoda&shmsize=0&target=&ulimits=null&version=1
DEBU[2019-07-15T11:59:20.687282279Z] Calling POST /session
INFO[2019-07-15T11:59:20.687761392Z] parsed scheme: "" module=grpc
INFO[2019-07-15T11:59:20.687833668Z] scheme "" not registered, fallback to default scheme module=grpc
INFO[2019-07-15T11:59:20.688017578Z] ccResolverWrapper: sending new addresses to cc: [{ 0 <nil>}] module=grpc
INFO[2019-07-15T11:59:20.688270160Z] ClientConn switching balancer to "pick_first" module=grpc
INFO[2019-07-15T11:59:20.688353083Z] pickfirstBalancer: HandleSubConnStateChange: 0xc4209b0630, CONNECTING module=grpc
INFO[2019-07-15T11:59:20.688985698Z] pickfirstBalancer: HandleSubConnStateChange: 0xc4209b0630, READY module=grpc
DEBU[2019-07-15T11:59:20.812700550Z] client is session enabled
DEBU[2019-07-15T11:59:20.813139288Z] FIXME: Got an API for which error does not match any expected type!!!: invalid argument
github.com/docker/docker/vendor/github.com/containerd/containerd/errdefs.init
/go/src/github.com/docker/docker/vendor/github.com/containerd/containerd/errdefs/errors.go:40
github.com/docker/docker/vendor/github.com/containerd/containerd/content.init
<autogenerated>:1
github.com/docker/docker/builder/builder-next.init
<autogenerated>:1
github.com/docker/docker/api/server/backend/build.init
<autogenerated>:1
main.init
<autogenerated>:1
runtime.main
/usr/local/go/src/runtime/proc.go:186
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:2361 error_type="*errors.fundamental" module=api
ERRO[2019-07-15T11:59:20.813210677Z] Handler for POST /v1.39/build returned error: "foobar": unknown operating system or architecture: invalid argument
DEBU[2019-07-15T11:59:20.813276737Z] FIXME: Got an API for which error does not match any expected type!!!: invalid argument
github.com/docker/docker/vendor/github.com/containerd/containerd/errdefs.init
/go/src/github.com/docker/docker/vendor/github.com/containerd/containerd/errdefs/errors.go:40
github.com/docker/docker/vendor/github.com/containerd/containerd/content.init
<autogenerated>:1
github.com/docker/docker/builder/builder-next.init
<autogenerated>:1
github.com/docker/docker/api/server/backend/build.init
<autogenerated>:1
main.init
<autogenerated>:1
runtime.main
/usr/local/go/src/runtime/proc.go:186
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:2361 error_type="*errors.fundamental" module=api
```
Same for the `docker pull --platform=foobar hello-world:latest` case:
```bash
docker pull --platform=foobar hello-world:latest
Error response from daemon: "foobar": unknown operating system or architecture: invalid argument
```
```
DEBU[2019-07-15T12:00:18.812995330Z] Calling POST /v1.39/images/create?fromImage=hello-world&platform=foobar&tag=latest
DEBU[2019-07-15T12:00:18.813229172Z] FIXME: Got an API for which error does not match any expected type!!!: invalid argument
github.com/docker/docker/vendor/github.com/containerd/containerd/errdefs.init
/go/src/github.com/docker/docker/vendor/github.com/containerd/containerd/errdefs/errors.go:40
github.com/docker/docker/vendor/github.com/containerd/containerd/content.init
<autogenerated>:1
github.com/docker/docker/builder/builder-next.init
<autogenerated>:1
github.com/docker/docker/api/server/backend/build.init
<autogenerated>:1
main.init
<autogenerated>:1
runtime.main
/usr/local/go/src/runtime/proc.go:186
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:2361 error_type="*errors.fundamental" module=api
ERRO[2019-07-15T12:00:18.813365546Z] Handler for POST /v1.39/images/create returned error: "foobar": unknown operating system or architecture: invalid argument
DEBU[2019-07-15T12:00:18.813461428Z] FIXME: Got an API for which error does not match any expected type!!!: invalid argument
github.com/docker/docker/vendor/github.com/containerd/containerd/errdefs.init
/go/src/github.com/docker/docker/vendor/github.com/containerd/containerd/errdefs/errors.go:40
github.com/docker/docker/vendor/github.com/containerd/containerd/content.init
<autogenerated>:1
github.com/docker/docker/builder/builder-next.init
<autogenerated>:1
github.com/docker/docker/api/server/backend/build.init
<autogenerated>:1
main.init
<autogenerated>:1
runtime.main
/usr/local/go/src/runtime/proc.go:186
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:2361 error_type="*errors.fundamental" module=api
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This test can fail if `eth0` has multiple IP addresses;
E docker.errors.APIError: 400 Client Error: Bad Request ("interface eth0 has more than one IPv6 address (2001:db8:1::242:ac11:2 and fe80::42:acff:fe11:2)")
Which is not a failiure, but depends on the environment that
the test is run in.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>