moby--moby/pkg
Ian Campbell 5894bc1abf Add `docker build --iidfile=FILE`
This is synonymous with `docker run --cidfile=FILE` and writes the digest of
the newly built image to the named file. This is intended to be used by build
systems which want to avoid tagging (perhaps because they are in CI or
otherwise want to avoid fixed names which can clash) by enabling e.g. Makefile
constructs like:

    image.id: Dockerfile
    	docker build --iidfile=image.id .

    do-some-more-stuff: image.id
    	do-stuff-with <image.id

Currently the only way to achieve this is to use `docker build -q` and capture
the stdout, but at the expense of losing the build output.

In non-silent mode (without `-q`) with API >= v1.29 the caller will now see a
`JSONMessage` with the `Aux` field containing a `types.BuildResult` in the
output stream for each image/layer produced during the build, with the final
one being the end product.  Having all of the intermediate images might be
interesting in some cases.

In silent mode (with `-q`) there is no change, on success the only output will
be the resulting image digest as it was previosuly.

There was no wrapper to just output an Aux section without enclosing it in a
Progress, so add one here.

Added some tests to integration cli tests.

Signed-off-by: Ian Campbell <ian.campbell@docker.com>
2017-05-05 16:35:54 +01:00
..
aaparser
archive
authorization
broadcaster
chrootarchive
devicemapper
directory
discovery
filenotify
fileutils
fsutils
gitutils
homedir
httputils
idtools
ioutils
jsonlog
jsonmessage Add `docker build --iidfile=FILE` 2017-05-05 16:35:54 +01:00
listeners
locker
longpath
loopback
mount
namesgenerator
parsers
pidfile
platform
plugingetter
plugins
pools
progress
promise
pubsub
random
reexec
registrar
signal
stdcopy
streamformatter Add `docker build --iidfile=FILE` 2017-05-05 16:35:54 +01:00
stringid
stringutils
symlink
sysinfo
system
tailfile
tarsum
templates
term
testutil
tlsconfig
truncindex
urlutil
useragent
README.md

README.md

pkg/ is a collection of utility packages used by the Docker project without being specific to its internals.

Utility packages are kept separate from the docker core codebase to keep it as small and concise as possible. If some utilities grow larger and their APIs stabilize, they may be moved to their own repository under the Docker organization, to facilitate re-use by other projects. However that is not the priority.

The directory pkg is named after the same directory in the camlistore project. Since Brad is a core Go maintainer, we thought it made sense to copy his methods for organizing Go code :) Thanks Brad!

Because utility packages are small and neatly separated from the rest of the codebase, they are a good place to start for aspiring maintainers and contributors. Get in touch if you want to help maintain them!