New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enqueue ONBUILD instructions from multiple ancestors #5714

fabiokung opened this Issue May 9, 2014 · 5 comments


None yet
5 participants

fabiokung commented May 9, 2014

I'm sorry for the lack of a better name for this feature request.

I want heroku buildpacks to be docker images. That way, Heroku apps could be built with Docker, generating both a valid docker container to run the app, and a valid Heroku slug that could be deployed to Heroku.

While playing with the idea, I found that all buildpacks will have a common set of ONBUILD instructions. Eg.: all buildpacks need to run their bin/compile against the app source code.

Initially I thought that chaining ONBUILD (#4244) in a base image for buildpacks could be a solution to avoid all buildpacks having to C&P a piece of shared Dockerfile:

Using Heroku buildpacks as Docker images to build apps.

Discussions on irc (#docker-dev) made me realize that ONBUILD ONBUILD may not be very flexible. It would only allow buildpack-base -> buildpack -> app hierarchies. Composing buildpack images (a.k.a. buildpack-multi) would not be possible that way (eg.: buildpack-base -> buildpack-ruby -> buildpack-pgbouncer -> app.

Some alternatives that were proposed:

  • Introspection: allow buildpacks to call docker --introspect --change "ONBUILD RUN ... and similar things during build. That way buildpack images could enqueue their ONBUILD commands and propagate ONBUILD commands from their ancestors.
  • Chained docker build invocations, as suggested by @proppy. It's not clear to me though how it would enable the use case I originally mentioned (Heroku buildpacks as docker images).
  • INCLUDE: #735. With it buildpacks could just add the shared set of commands to their Dockerfiles.

Any other ideas? I'm happy to help with code and PRs once we settle on a design.


This comment has been minimized.


proppy commented May 17, 2014

Another alternative would be to add a new instruction like TRIGGER ONBUILD <base/image> that explictly trigger the ONBUILD instructions from a given ancestor image.

(Along with the possibility to do ONBUILD TRIGGER ONBUILD it forward ONBUILD instructions to child images :)

Note: chained docker build is about splitting the builder and the runner image, see #5715


This comment has been minimized.


proppy commented May 17, 2014

Another perhaps more elegant solution would be to have #comment annotations to specify if you want to opt in or opt out executing ONBUILD instructions after FROM.

Something like:

FROM base/image # +onbuild
FROM base/image # -onbuild

This comment has been minimized.

gastonmorixe commented Feb 17, 2015

Guys any update on this? this is extremely needed. In my rails application I use FROM rails:onbuild but I need a middle image to add some stuff, which doesn't yet have the rails app files.


This comment has been minimized.

gastonmorixe commented Feb 17, 2015

I'd like to resquest ONBUILD inheritance, is this possible?


This comment has been minimized.


jessfraz commented Jul 10, 2015

We are no longer accepting patches to the Dockerfile syntax as you can read about here:


Allowing the Builder to be implemented as a separate utility consuming the Engine's API will open the door for many possibilities, such as offering alternate syntaxes or DSL for existing languages without cluttering the Engine's codebase

Then from there, patches/features like this can be re-thought. Hope you can understand.

@jessfraz jessfraz closed this Jul 10, 2015

envision added a commit to envision/ that referenced this issue Aug 22, 2018

Fix broken link to ONBUILD variants in "Dockerfile best practices"
Ruby has [dropped ONBUILD variants](
'While the onbuild variant is really useful for "getting off the ground running" (zero to Dockerized in a short period of time), it's not recommended for long-term usage within a project due to the lack of control over when the ONBUILD triggers fire (see also moby/moby#5714, moby/moby#8240, moby/moby#11917).'

Changed the link to a Maven's similar example.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment