This fix fixes a couple of incorrect version strings in swagger.yaml
`v1.25` should be `v1.26`. This applies to 1.14 version only.
Also checked 1.13rc and it is fine.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 887c4188f469698938213eddd1babf224cc39737
Component: engine
This reverts 26103. 26103 was trying to make it so that if someone did:
docker build --build-arg FOO .
and FOO wasn't set as an env var then it would pick-up FOO from the
Dockerfile's ARG cmd. However, it went too far and removed the ability
to specify a build arg w/o any value. Meaning it required the --build-arg
param to always be in the form "name=value", and not just "name".
This PR does the right fix - it allows just "name" and it'll grab the value
from the env vars if set. If "name" isn't set in the env then it still needs
to send "name" to the server so that a warning can be printed about an
unused --build-arg. And this is why buildArgs in the options is now a
*string instead of just a string - 'nil' == mentioned but no value.
Closes#29084
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: cdb8ea90b04683adb25c8ccd71b6eaedc44b51e2
Component: engine
- Display the ID column
- Do not append the task ID in the name column
- (NEW): Truncate task IDs, unless --no-trunc is specified
Signed-off-by: Andrea Luzzardi <aluzzardi@gmail.com>
Upstream-commit: bbd2018ee19eff5594ae3986bf56fbcd0044699d
Component: engine
This removes some very old vestigial code that really should have been
removed during the content addressability transition. It implements
something called "reference" but it behaves differently from the actual
reference package. This was only used by client-side content trust code,
and is relatively easy to extricate.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: d91ed88365317cd86555e2f54bffa30ec6590dfe
Component: engine
Otherwise, while using test-integration-shell, it runs the tests using
the previously compiled test binary.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: aefbc034445df17c98f1247b100e2b6a2ed22e84
Component: engine
In certain cases (unattended upgrades), system services can disable
loaded AppArmor profiles. However, since /etc being read-only is a
supported setup we cannot just write a copy of the profile to
/etc/apparmor.d.
Instead, dynamically load the docker-default AppArmor profile if a
container is started with that profile set. This code will short-cut if
the profile is already loaded.
Fixes: 2f7596aaef3a ("apparmor: do not save profile to /etc/apparmor.d")
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Upstream-commit: 567ef8e7858ca4f282f598ba1f5a951cbad39e83
Component: engine
v2/Plugin struct had fields that were
- purely used by the manager.
- unsafely exposed without proper locking.
This change fixes this, by moving relevant fields to the manager as well
as making remaining fields as private and providing proper accessors for
them.
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: b35490a8ba2ad70a585c1ba8109b6d87aece8daa
Component: engine
This fix tries to address the issue raised on 29185 where
`docker inspect <unknown object>` on Windows will return:
```
Error response from daemon: plugins are not supported on this platform
```
The reason was that in case `--type` is not specified, `docker inspect`
will iterate through different types `container`, `image`, `network`,
`plugin` etc. The `plugin` object is the last type to check.
However, as `plugin` is not supported on Windows yet, the error message
is not very informative for `plugins are not supported on this platform`.
This fix tries to fix the issue by return a `not found` error on unsupported
platforms as well.
An integration test has been added to cover the changes for Windows/Linux.
This fix fixes 29185.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 88fcdb0a825da040ef2b1f9c191af480f0f2cc90
Component: engine
This fix tries to address the issue raised in 29129 where
"--hostname" not working when running in "--net=host" for
`docker run`.
The fix fixes the issue by not resetting the `container.Config.Hostname`
if the `Hostname` has already been assigned through `--hostname`.
An integration test has been added to cover the changes.
This fix fixes 29129.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: b0a7b0120f4461daa34527a743087e73ef8f5963
Component: engine
Some containers were being built (`docker build`) without
the DOCKER_BUILD_ARGS variable, which was causing some
issues because of the lack of network proxy configuration.
Fixes#29132
Signed-off-by: Luiz Svoboda <luizek@gmail.com>
Upstream-commit: 63aaf5e316d7b51db9be94bcb16dab07fdf1fdb4
Component: engine
