enqueue ONBUILD instructions from multiple ancestors #5714
Comments
|
Another alternative would be to add a new instruction like (Along with the possibility to do Note: chained |
|
Another perhaps more elegant solution would be to have #comment annotations to specify if you want to opt in or opt out executing Something like: |
|
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. |
|
I'd like to resquest ONBUILD inheritance, is this possible? |
|
Hello! Mainly:
Then from there, patches/features like this can be re-thought. Hope you can understand. |
Ruby has [dropped ONBUILD variants](https://hub.docker.com/_/rails/): '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.
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
ONBUILDinstructions. Eg.: all buildpacks need to run theirbin/compileagainst 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 ONBUILDmay not be very flexible. It would only allowbuildpack-base -> buildpack -> apphierarchies. 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:
docker --introspect --change "ONBUILD RUN ...and similar things during build. That way buildpack images could enqueue theirONBUILDcommands and propagateONBUILDcommands from their ancestors.docker buildinvocations, 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: Proposal: Dockerfile add 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.
The text was updated successfully, but these errors were encountered: