This PR adds a "request ID" to each event generated, the 'docker events'
stream now looks like this:
```
2015-09-10T15:02:50.000000000-07:00 [reqid: c01e3534ddca] de7c5d4ca927253cf4e978ee9c4545161e406e9b5a14617efb52c658b249174a: (from ubuntu) create
```
Note the `[reqID: c01e3534ddca]` part, that's new.
Each HTTP request will generate its own unique ID. So, if you do a
`docker build` you'll see a series of events all with the same reqID.
This allow for log processing tools to determine which events are all related
to the same http request.
I didn't propigate the context to all possible funcs in the daemon,
I decided to just do the ones that needed it in order to get the reqID
into the events. I'd like to have people review this direction first, and
if we're ok with it then I'll make sure we're consistent about when
we pass around the context - IOW, make sure that all funcs at the same level
have a context passed in even if they don't call the log funcs - this will
ensure we're consistent w/o passing it around for all calls unnecessarily.
ping @icecrime @calavera @crosbymichael
Signed-off-by: Doug Davis <dug@us.ibm.com>
- The build-time variables are passed as environment-context for command(s)
run as part of the RUN primitve. These variables are not persisted in environment of
intermediate and final images when passed as context for RUN. The build environment
is prepended to the intermediate continer's command string for aiding cache lookups.
It also helps with build traceability. But this also makes the feature less secure from
point of view of passing build time secrets.
- The build-time variables also get used to expand the symbols used in certain
Dockerfile primitves like ADD, COPY, USER etc, without an explicit prior definiton using a
ENV primitive. These variables get persisted in the intermediate and final images
whenever they are expanded.
- The build-time variables are only expanded or passed to the RUN primtive if they
are defined in Dockerfile using the ARG primitive or belong to list of built-in variables.
HTTP_PROXY, HTTPS_PROXY, http_proxy, https_proxy, FTP_PROXY and NO_PROXY are built-in
variables that needn't be explicitly defined in Dockerfile to use this feature.
Signed-off-by: Madhav Puri <madhav.puri@gmail.com>
With the 1.7 release, we introduced a change to how we store registry
credentials, but the build API endpoint did not expect a change in the format
of that file. This patch fixes this problem so that you can again pull private
images during `docker build`.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
This fixes an issue where the build output for the "Steps" would look like:
```
Step 1: RUN echo hi echo hi
```
instead of
```
Step 1: RUN echo hi
```
Also, I noticed that there were no checks to make sure invalid Dockerfile
cmd flags were caught on cmds that didn't use cmd flags at all. They would
have been caught on the cmds that had flags, but cmds that didn't bother
to add a new code for flags would have just ignored them. So, I added
checks to each cmd to flag it.
Added testcases for issues.
Signed-off-by: Doug Davis <dug@us.ibm.com>
This adds support for Dockerfile commands to have options - e.g:
COPY --user=john foo /tmp/
COPY --ignore-mtime foo /tmp/
Supports both booleans and strings.
Signed-off-by: Doug Davis <dug@us.ibm.com>
This PR does the following:
- migrated ~/.dockerfg to ~/.docker/config.json. The data is migrated
but the old file remains in case its needed
- moves the auth json in that fie into an "auth" property so we can add new
top-level properties w/o messing with the auth stuff
- adds support for an HttpHeaders property in ~/.docker/config.json
which adds these http headers to all msgs from the cli
In a follow-on PR I'll move the config file process out from under
"registry" since it not specific to that any more. I didn't do it here
because I wanted the diff to be smaller so people can make sure I didn't
break/miss any auth code during my edits.
Signed-off-by: Doug Davis <dug@us.ibm.com>
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>
- command.Commands was missing "Label"
- used the correct error string in dispatcher when LABEL has no args, otherwise
the test TestBuildMissingArgs will not work
- removed the premature error msg in line_parser that was blocking the
label() func in dispatcher from showing the err msg in previous bullet
- since LABEL uses the env parser it needs to be added to the replaceEnvAllowed
list so that proper quote processing will be done. Especially once
PR #10431 is merged.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Instead of just printing a warning and going on, this will generate
an error and stop processing.
This used to be part of #10561 but I decided it might need its own
independent discussion/PR as to not derail #10561.
Signed-off-by: Doug Davis <dug@us.ibm.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)
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>
Instead of building the actual image, `build_config` will serialize a subset of
dockerfile ast into *runconfig.Config
Docker-DCO-1.1-Signed-off-by: Daniel, Dao Quang Minh <dqminh89@gmail.com> (github: dqminh)
Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
d1e9d07c introduces a dependency to libcontainer and other daemon
related packages through builder package. The only thing test needs
is set of the Dockerfile commands. Extracting them to a separate
package.
This was causing CI tests to not to compile on non-Linux platforms.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
If you have a Dockefile with just:
FROM scratch
An error is generated but its never shown to the CLI. This PR fixes that.
Signed-off-by: Doug Davis <dug@us.ibm.com>
We're hoping to add some new commands that don't have any args so this
PR will enable that by removing all of the hard-coded checks that require
commands to have at least one arg. It also adds some checks to each
command so we're consistent in the error message we get. Added a test
for this too.
We actually had this check in at least 3 different places (twice in the
parser and once in most cmds), this removes 2 of them (the parser ones).
Had to remove/modify some testcases because its now legal to have certain
commands w/o args - e.g. RUN. This was actually inconsistent because
we used to allow "RUN []" but not "RUN" even though they would generate
(almost) the same net result. Now we're consistent.
Signed-off-by: Doug Davis <dug@us.ibm.com>
I noticed that while we have tests to make sure that people don't
specify a Dockerfile (via -f) that's outside of the build context
when using the docker cli, we don't check on the server side to make
sure that API users have the same check done. This would be a security
risk.
While in there I had to add a new util func for the tests to allow us to
send content to the server that isn't json encoded - in this case a tarball
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>
