There has been a lot of discussion (issues 4242 and 5262) about making
`FROM scratch` either a special case or making `FROM` optional, implying
starting from an empty file system.
This patch makes the build command `FROM scratch` special cased from now on
and if used does not pull/set the the initial layer of the build to the ancient
image ID (511136ea..) but instead marks the build as having no base image. The
next command in the dockerfile will create an image with a parent image ID of "".
This means every image ever can now use one fewer layer!
This also makes the image name `scratch` a reserved name by the TagStore. You
will not be able to tag an image with this name from now on. If any users
currently have an image tagged as `scratch`, they will still be able to use that
image, but will not be able to tag a new image with that name.
Goodbye '511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158',
it was nice knowing you.
Fixes#4242
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Upstream-commit: 8936789919c5c8004f346f44a3452d1521818b60
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
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
Sometimes rm begins before process death, but Kill called already after
it, so we get error - no such process.
Signed-off-by: Alexandr Morozov <lk4d4@docker.com>
Upstream-commit: 0d70ad1c7205ba9e82dd1f244d26df93dc79de9e
Component: engine
Fix a regression introduced in PR#9467 when a single file was added or
copied.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: cfc24769a26e825e4267cbfdd59af807e27508b9
Component: engine
Forbid `docker run -t` with a redirected stdin (such as `echo test |
docker run -ti busybox cat`). Forbid `docker exec -t` with a redirected
stdin. Forbid `docker attach` with a redirect stdin toward a tty enabled
container.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: 67e3ddb75ff27b8de0022e330413b4308ec5b010
Component: engine
Permissions after an ADD or COPY build instructions are now restricted
to the scope of files potentially modified by the operation rather than
the entire impacted tree.
Fixes#9401.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: f3cedce3608afe7bd570666a7fc878ab85c7bc03
Component: engine
Right now 'docker build' will send:
Sending build context to Docker daemon
to stderr, instead of stdout. This PR fixes that.
I looked in the rest of api/client/commands.go for other cases
that might do this and only one jumped out at me:
https://github.com/docker/docker/blob/master/api/client/commands.go#L2202
but I think if I changed that to go to stdout then it'll mess people up
who are expecting just the container ID to be printed to the screen and
there is no --quiet type of flag we can check.
Closes#9404
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 5c91bb93a7e35b2d443090cabc7ec0a2ca59b6ee
Component: engine
Add the test case of this issue.
Docker-DCO-1.1-Signed-off-by: Chen Chao <cc272309126@gmail.com> (github: cc272309126)
Upstream-commit: 1bb02117db80e75f406f6c63d8d50680c1569019
Component: engine
Sometimes other programs can bind on ports from our range, so we just
skip this ports on allocation.
Fixes#9293
Probably fixes#8714
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: a00a1a1fca020d21cb677439160e018bda5c3835
Component: engine
Note - only support the non-detached mode of exec right now.
Another PR will add -d support.
Closes#8703
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 90928eb1140fc0394e2a79d5e9a91dbc0f02484c
Component: engine
