Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: TRIGGER Dockerfile instruction #8240
Proposal: TRIGGER Dockerfile instruction
This is a proposal to generalize the
It allows user to easily Dockerize their application, w/ very few instruction in their Dockerfile:
So if you have a base with:
and a child image with
It will result into
However if you have a child image with:
It will result into:
Causing the layer w/
If a parent image define:
A child image can decide where to trigger the
The default would still be to
(#maybe #later #oneday)
The mecanism could be then be extended to allow triggering any Dockerfile instructions annotated in the parent image.
See the over complicated example below:
I like the general concept and possibility of future expansion, it's great to have more control over the triggers. Also agree that the syntax and behavior need some refining. I suggest to create "roadmap" that defines the initial implementation, and described how to improve on that in a later stage.
One thing that comes in mind is to disable or "skip" an
I really like this proposal but I would be cool to make it more explicit that those 'macros' are things defined in the parent Dockerfile. This could be done by extending the FROM to specify which "macros" you want to use (based on the child example in the proposal):
That way it's explicit that those macros come from the parent image.
Beside that, with this in place you can use a 'ON-BUILD' base image even if you don't want any of those macros to run (no need for golang + golang:onbuild!):
But in the golang image case I think I would prefer to have the golang base define