Feature Request: "AND" instruction in Dockerfile

[nnordrum]

A Dockerfile can get pretty unwieldy when you're trying to minimize the number of intermediary images. Dockerfile Best Practices dictate using && to condense multiple commands into a single RUN instruction, but this can cause issues trying to decipher what went wrong on step 32 of a composite RUN instruction.

I propose adding a AND instruction which behaves essentially the same as a RUN instruction. Differences I'm aware of would be:
Now:
RUN

• creates a container, executes the command
• commits the container

Proposed:
RUN

• creates a container, executes a command
• commits a container IF there aren't any directly connected AND instructions

AND

• must be immediately preceded by a RUN or another AND instruction
• IF the previous RUN/AND instruction had exit code 0
  • executes a command in the container created by the current RUN instruction
• ELSE
  • stop processing the Dockerfile (as RUN currently does when it errors)

Example:
Now:

RUN apt-get update -qqy \
  && apt-get -qqy --no-install-recommends install \
    fonts-ipafont-gothic \
    xfonts-100dpi \
    xfonts-75dpi \
    xfonts-cyrillic \
    xfonts-scalable \
  && rm -rf /var/lib/apt/lists/*

Proposed:

RUN apt-get update -qqy 
AND apt-get -qqy --no-install-recommends install \
    fonts-ipafont-gothic \
    xfonts-100dpi xfonts-75dpi \
    xfonts-cyrillic xfonts-scalable
AND rm -rf /var/lib/apt/lists/*

This should be 100% backwards compatible because we wouldn't be altering the behavior of RUN when there aren't any AND instructions. This wouldn't prevent you from using && in a RUN or AND instruction.

What it would do is add clarity to the Dockerfile during build time, while retaining the intended number of intermediary images.

I thought about just joining multiple RUN statements, but then you need an instruction to delineate intermediary images, and that has a _huge_ impact on backwards compatibility.

[phemmer]

This is similar to other proposals that have come up in the past. See #332 and #6906

[nnordrum]

https://github.com/docker/docker/blob/master/ROADMAP.md#22-dockerfile-syntax

I didn't see this. Boo.

[unclejack]

The builder is going to be moved out of the Docker daemon. This will make it possible to implement all kinds of changes and extensions. As you've also mentioned above, the builder code currently couples every RUN operation to one layer and that's how it's going to be until the builder is moved out of the daemon. However, once the builder code is moved out of the Docker daemon, things should be much easier.

The builder code as it is today in the Docker daemon won't be changed any more.

After reading and thinking about this request, I'm closing this issue now for the following reasons:

• the current builder code is frozen as it is
• new instructions, custom extensions and custom builders will be possible once the builder code is moved out of the Docker daemon

Please feel free to comment.

[nnordrum]

Any ballpark eta on when it gets moved out? 2016? 2017?

[beorn]

I like this solution to the flattening of layers, except why not allow the AND keyword to precede any Dockerfile command?

[Krijger]

I wanted to propose almost exactly the same feature. However, with @beorn idea as well. It would be something like

FROM bla
# install
ADD install.sh /
AND RUN chmod +x /install.sh
AND RUN /install.sh
AND RUN rm /install.sh
# expose installed-service ports
EXPOSE 1234
AND EXPOSE 5678

Indeed, AND should be allowed to precede any normal Dockerfile keyword - it should not imply a RUN. The above file would result in 2 file layers. Local caching should be possible.

Looking forward to unfreeze of builder code. I do think this should be an included battery, so to speak :)

[akostadinov]

Is there a bug tracker where factoring out the builder from daemon is tracked?