mirror of https://github.com/docker/cli.git
New build instruction: ONBUILD defines a trigger to execute when extending an image with a new build
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <solomon@docker.com> (github: shykes)
This commit is contained in:
parent
05c073b292
commit
8bef3842d7
|
@ -402,6 +402,64 @@ the image.
|
||||||
The ``WORKDIR`` instruction sets the working directory in which
|
The ``WORKDIR`` instruction sets the working directory in which
|
||||||
the command given by ``CMD`` is executed.
|
the command given by ``CMD`` is executed.
|
||||||
|
|
||||||
|
3.11 ONBUILD
|
||||||
|
------------
|
||||||
|
|
||||||
|
``ONBUILD [INSTRUCTION]``
|
||||||
|
|
||||||
|
The ``ONBUILD`` instruction adds to the image a "trigger" instruction to be
|
||||||
|
executed at a later time, when the image is used as the base for another build.
|
||||||
|
The trigger will be executed in the context of the downstream build, as if it
|
||||||
|
had been inserted immediately after the *FROM* instruction in the downstream
|
||||||
|
Dockerfile.
|
||||||
|
|
||||||
|
Any build instruction can be registered as a trigger.
|
||||||
|
|
||||||
|
This is useful if you are building an image which will be used as a base to build
|
||||||
|
other images, for example an application build environment or a daemon which may be
|
||||||
|
customized with user-specific configuration.
|
||||||
|
|
||||||
|
For example, if your image is a reusable python application builder, it will require
|
||||||
|
application source code to be added in a particular directory, and it might require
|
||||||
|
a build script to be called *after* that. You can't just call *ADD* and *RUN* now,
|
||||||
|
because you don't yet have access to the application source code, and it will be
|
||||||
|
different for each application build. You could simply provide application developers
|
||||||
|
with a boilerplate Dockerfile to copy-paste into their application, but that is
|
||||||
|
inefficient, error-prone and difficult to update because it mixes with
|
||||||
|
application-specific code.
|
||||||
|
|
||||||
|
The solution is to use *ONBUILD* to register in advance instructions to run later,
|
||||||
|
during the next build stage.
|
||||||
|
|
||||||
|
Here's how it works:
|
||||||
|
|
||||||
|
1. When it encounters an *ONBUILD* instruction, the builder adds a trigger to
|
||||||
|
the metadata of the image being built.
|
||||||
|
The instruction does not otherwise affect the current build.
|
||||||
|
|
||||||
|
2. At the end of the build, a list of all triggers is stored in the image manifest,
|
||||||
|
under the key *OnBuild*. They can be inspected with *docker inspect*.
|
||||||
|
|
||||||
|
3. Later the image may be used as a base for a new build, using the *FROM* instruction.
|
||||||
|
As part of processing the *FROM* instruction, the downstream builder looks for *ONBUILD*
|
||||||
|
triggers, and executes them in the same order they were registered. If any of the
|
||||||
|
triggers fail, the *FROM* instruction is aborted which in turn causes the build
|
||||||
|
to fail. If all triggers succeed, the FROM instruction completes and the build
|
||||||
|
continues as usual.
|
||||||
|
|
||||||
|
4. Triggers are cleared from the final image after being executed. In other words
|
||||||
|
they are not inherited by "grand-children" builds.
|
||||||
|
|
||||||
|
For example you might add something like this:
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
[...]
|
||||||
|
ONBUILD ADD . /app/src
|
||||||
|
ONBUILD RUN /usr/local/bin/python-build --dir /app/src
|
||||||
|
[...]
|
||||||
|
|
||||||
|
|
||||||
.. _dockerfile_examples:
|
.. _dockerfile_examples:
|
||||||
|
|
||||||
4. Dockerfile Examples
|
4. Dockerfile Examples
|
||||||
|
|
Loading…
Reference in New Issue