* Upgrade to latest Sphinx / recommonmark
* Small CSS fix for issue in new version of Alabaster theme
* Fix `Makefile` target for macOS
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
* Fix integration tests race condition
* Run integration tests on CI
* Use existing DIND version
Signed-off-by: Leonard Kinday <leonard@kinday.ru>
Co-authored-by: Milas Bowman <milas.bowman@docker.com>
Specific TLS versions are deprecated in latest Python, which
causes test failures due to treating deprecation errors as
warnings.
Luckily, the fix here is straightforward: we can eliminate some
custom version selection logic by using `PROTOCOL_TLS_CLIENT`,
which is the recommended method and will select the highest TLS
version supported by both client and server.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
We want "The above exception was the direct cause of the following exception:" instead of "During handling of the above exception, another exception occurred:"
Signed-off-by: Maor Kleinberger <kmaork@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>
This was using a deprecated function (`urllib.splitnport`),
ostensibly to work around issues with brackets on IPv6 addresses.
Ironically, its usage was broken, and would result in mangled IPv6
addresses if they had a port specified in some instances.
Usage of the deprecated function has been eliminated and extra test
cases added where missing. All existing cases pass as-is. (The only
other change to the test was to improve assertion messages.)
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Upgrade to latest pywin32, which has support for Python 3.10 and
resolves a CVE (related to ACL APIs, outside the scope of what
`docker-py` relies on, which is npipe support, but still gets
flagged by scanners).
The version constraint has also been relaxed in `setup.py` to allow
newer versions of pywin32. This is similar to how we handle the
other packages there, and should be safe from a compatibility
perspective.
Fixes#2902.
Closes#2972 and closes#2980.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Milas Bowman