This tests ensures that the content from a dir within a build is carried
over even if VOLUME for that dir is specified in the Dockerfile. This
test ensures this long standing functionality.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: eac27ad46d7df4f11a28b84130ff484224f8b63d
Component: engine
Fixed two misspellings of the word "beginning".
Signed-off-by: JacobEdelman <edelman.jd@gmail.com>
Upstream-commit: 97f07bb61ccf6e5a3a0fcc72894d5f37310d0109
Component: engine
_docker_run and _docker_create had only one differing line.
This refactoring features:
- direct completion for both commands to the same function
- factor out the common arguments, sort & format them nicely
- compute the argument for _docker_pos_first_nonflag.
Signed-off-by: Harald Albers <github@albersweb.de>
Upstream-commit: 46b104bd3977c4777b0d99ba6c190f37ae780245
Component: engine
When we use the engine/env object we can run into a situation where
a string is passed in as the value but later on when we json serialize
the name/value pairs, because the string is made up of just numbers
it appears as an integer and not a string - meaning no quotes. This
can cause parsing issues for clients.
I tried to find all spots where we call env.Set() and the type of the
name being set might end up having a value that could look like an int
(like author). In those cases I switched it to use env.SetJson() instead
because that will wrap it in quotes.
One interesting thing to note about the testcase that I modified is that
the escaped quotes should have been there all along and we were incorrectly
letting it thru. If you look at the metadata stored for that resource you
can see the quotes were escaped and we lost them during the serialization
steps because of the env.Set() stuff. The use of env is probably not the
best way to do all of this.
Closes: #9602
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: d942c59b696d16def85f6b65ae65c176f66a5562
Component: engine
Because this is already tested by TestRunExitOnStdinClose in
integration-cli/docker_cli_run_test.go
Signed-off-by: Alexandr Morozov <lk4d4@docker.com>
Upstream-commit: 4d7359f63db200298f9d07f6434a7a4b16c25c88
Component: engine
This test tests nothing because of error in cmd, where "echo 'should
fail'" passed as binary. Also this test directly contradicts
documentation and current daemon behavior.
Fixes#7826
Signed-off-by: Alexandr Morozov <lk4d4@docker.com>
Upstream-commit: 70a2b64ef2e31aef84c39b979686e9194aee22a6
Component: engine
When the user is not using the full has to retrieve a container it's
possible that we find conflicts with the ids of other containers.
At the moment it's just failing saying that it can not find a container,
but it doesn't say why. Adding a small log saying that duplicates where
found is going to help the user.
Closes#8098
Signed-off-by: Alex Gonzalez <agonzalezro@gmail.com>
Upstream-commit: be27d97118764db994fbaf3632225a691c7418fb
Component: engine
Fixed a missing link and a few small formatting issues. Also deleted 1.3 notes as originally intended.
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
Upstream-commit: afc262cc3ab68129104e3d799f8a2694f61aa68f
Component: engine
This tests ensures that the content from a dir within a build is carried
over even if VOLUME for that dir is specified in the Dockerfile. This
test ensures this long standing functionality.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 4856ec075422a7926b62762749a7fbcc869efa99
Component: engine
