Add the capability to cancel the build by disconnecting the client.
This adds a `cancelled` channel which is used to signal that a build
should halt. The build is halted by sending a Kill signal and noticing
that the cancellation channel is closed.
This first pass implementation does not allow cancellation during a
pull, but that will come in a subsequent PR.
* Add documentation of cancellation to cli and API
* Protect job cancellation with sync.Once
* Add TestBuildCancelationKillsSleep
* Add test case for build cancellation of RUN statements.
Signed-off-by: Peter Waller <p@pwaller.net>
Closes#10191
Allow `docker build` to set --cpu-shares, --cpuset, --memory,
--memory-swap for all containers created by the build.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Add ability to refer to an image by repository name and digest using the
format repository@digest. Works for pull, push, run, build, and rmi.
Signed-off-by: Andy Goldstein <agoldste@redhat.com>
Adds more documentation for labels and adds the label instruction to the
man-pages.
Also included is a document called "Labels - custom meta-data in Docker"
in the user-guide, this is still a work-in-progress I started to describe
the "namespaces" conventions, an example on storing structured data.
I ran a bit "out of steam" (writers block?) on that document, but kept
it in (for now), in case it still ends up useful.
The Remote API documentation changes will need to be moved to the
docker_remote_api_v1.18.md document when rebasing the whole PR.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Darren Shepherd <darren@rancher.com>
Save "LABEL" field in Dockerfile into image content.
This will allow a user to save user data into an image, which
can later be retrieved using:
docker inspect IMAGEID
I have copied this from the "Comment" handling in docker images.
We want to be able to add Name/Value data to an image to describe the image,
and then be able to use other tools to look at this data, to be able to do
security checks based on this data.
We are thinking about adding version names,
Perhaps listing the content of the dockerfile.
Descriptions of where the code came from etc.
This LABEL field should also be allowed to be specified in the
docker import --change LABEL:Name=Value
docker commit --change LABEL:Name=Value
Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
Cgroup resources are host dependent, they should be in hostConfig.
For backward compatibility, we just copy it to hostConfig, and leave it in
Config for now, so there is no regressions, but the right way to use this
throught json is to put it in HostConfig, like:
{
"Hostname": "",
...
"HostConfig": {
"CpuShares": 512,
"Memory": 314572800,
...
}
}
As we will add CpusetMems, CpusetCpus is definitely a better name, but some
users are already using Cpuset in their http APIs, we also make it compatible.
The main idea is keep using Cpuset in Config Struct, and make it has the same
value as CpusetCpus, but not always, some scenarios:
- Users use --cpuset in docker command, it can setup cpuset.cpus and can
get Cpuset field from docker inspect or other http API which will get
config info.
- Users use --cpuset-cpus in docker command, ditto.
- Users use Cpuset field in their http APIs, ditto.
- Users use CpusetCpus field in their http APIs, they won't get Cpuset field
in Config info, because by then, they should already know what happens
to Cpuset.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
This change adds daemon's system time as RFC3339Nano to the `/info` endpoint
and shows in a more readable format (UnixDate) in `docker -D info` output.
I will be using this to fix the clock skew between the remote test host and
the CI machines running `docker events`-related tests as they're using `--since`
and `--until` and the timestamps are not matching when daemon is not on the
same machine.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
Closes#10807
Adds support for `dockerfile` ONLY when `Dockerfile` can't be found.
If we're building from a Dockerfile via stdin/URL then always download
it a `Dockerfile` and ignore the -f flag.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Update the "Docker Remote API Client Libraries" documentation page to
include a reference to the Go-based docker-reg-client package.
Signed-off-by: Brian DeHamer <brian@dehamer.com>
Introduced in Docker v0.4.5 / Remove API v1.1 (#848), the remote
parameter of the API method POST /build allows to specify a buildable
remote URL (HTTPS, HTTP or Git).
Signed-off-by: Vincent Giersch <vincent.giersch@ovh.net>
The API documentation uses the "base" image in various
places. The "base" image is deprecated and it is no longer
possible to download this image.
This changes the API documentation to use "ubuntu" in stead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add a --readonly flag to allow the container's root filesystem to be
mounted as readonly. This can be used in combination with volumes to
force a container's process to only write to locations that will be
persisted. This is useful in many cases where the admin controls where
they would like developers to write files and error on any other
locations.
Closes#7923Closes#8752
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
It seems odd to have such an important API hidden under 'misc'.
While in there I noticed that during the "-f Dockerfile" PR I changed
the query param from f to dockerfile and missed this one spot in the docs.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Add a check to make sure Dockerfile is in the build context
Add docs and a testcase
Make -f relative to current dir, not build context
Signed-off-by: Doug Davis <dug@us.ibm.com>
This is:
git format-patch -1 --stdout HEAD \
| patch -p1 docs/sources/reference/api/docker_remote_api_v1.*.md
Applying the changes I initially made on the docs for v1.15 to all
other versions led to acceptable results.
Signed-off-by: Lorenz Leutgeb <lorenz.leutgeb@gmail.com>
Fixed:
* Invalid JSON
* Inconsistent spacing at colon
Expression for binary data streams (line 468 vs. 1474) remain inconsistent.
Could fix that too, if you like.
Signed-off-by: Lorenz Leutgeb <lorenz.leutgeb@gmail.com>
Adds pertitent information about what is expected in the json payload
and comments out unsupported (exec) features in runConfig.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Alexander Morozov