@shykes This needs rebased but I look forward to playing with this feature.

Docs - LGTM - I too look forward to more awesomeness

@metalivedev @kencochrane @jamtur01

My only concern is how transparent this is - obviously it's in the upstream Dockerfile but is there some way of inspecting the image and seeing the ONBUILD instructions? I don't like magic I can't introspect or things that might be unexpected for the end user.

Yes, it's a new field in the image format and it will be visible in "docker inspect". We can adapt the end-user experience to give extra notice, allow more readable inspection etc. I'm open to suggestions. The only change so far is that the triggers are clearly printed out to the final build output, eg. "Executing 2 build triggers". I'm totally open to making more changes.

One thing to keep in mind is that this totally sandboxed to the build context. Yes, you can upload arbitrary parts of the source directory but nothing outside it. And you can execute arbitrary commands in the container but not outside (and builds cannot be privileged currently, if they do that changes things somewhat).

On Thu, Dec 19, 2013 at 3:43 PM, James Turnbull [email protected]
wrote:

My only concern is how transparent this is - obviously it's in the upstream Dockerfile but is there some way of inspecting the image and seeing the ONBUILD instructions? I don't like magic I can't introspect or things that might be unexpected for the end user.

Reply to this email directly or view it on GitHub:
#3254 (comment)

Hey Solomon,

Do you believe this would be a better direction than required parameters (or environment variables) in the container? I realize they are slightly different requests, but it seems to solve the same "configuration" problem.

@odonnellryan I think they are both useful and not mutually exclusive.

@odonnellryan specifically:

• Required params/variables make runtime configuration more powerful and nicer to use.
• onbuild makes builds more powerful, and reduces the number of cases where you need creative runtime configuration.

So on the one hand you get more opportunities to ship an image that "just works" without tons of runtime configuration (onbuild). On the other hand when you do need runtime configuration, it's more powerful (required params).

That's my current thinking anyway.

@shykes Thanks Solomon! I'm going to continue working on a required param feature. I agree with where you're going.

Rebased on master.

Ping @crosbymichael @vieux @creack

Could you give more information about when the ONBUILD instructions will be run? You say that "all on-build [sic.] instructions will be called in sequence, in the same order they were registered" but how does the execution of ONBUILD commands relate to non-ONBUILD commands?

I presume that non-ONBUILD commands in the "FROM image" tree will be ignored. If that's true, then it still leaves open the question of when the inherited ONBUILD commands get executed in relation to the current Dockerfile commands (ONBUILD and other).

ONBUILD in the current Dockerfile:

• Do inherited ONBUILD commands run invisibly right after the FROM step? Or are they deferred until the first ONBUILD in the current Dockerfile? I say "invisibly" because they're not part of the FROM and they're not in the current Dockerfile.
• Do the ONBUILD commands in the current Dockerfile get executed in the current Dockerfile build, or are they skipped now and always deferred to run when called through a FROM statement?

In your docs it seems like ONBUILD statements get deferred until the image is inherited through a FROM statement. But if the ONBUILD commands are required for image functionality, and they haven't been run, does that mean you expect people to duplicate the ONBUILD commands with RUN commands? so that the RUN gets done in the current build and the ONBUILD gets run in the future build?

To further question, how deep does it go? For example, if I have a Dockerfile that uses ONBUILD, then build a new one FROM the result, and then have a third Dockerfile that I FROM that image in, does the third Dockerfile/FROM invoke the ONBUILD clauses too?

So, in light of @metalivedev's comments, why not call the instruction ON-BUILD too? The parser currently handles hyphens swell (as noted by the fact that it doesn't mind our DOCKER-VERSION instruction), and this is our first real two-word instruction, isn't it?

This also makes it cleaner looking if we ever add future ON-* instructions.

@tianon re: depth, it only applies to the next build. Triggers are not passed to "grandchildren" builds.

On Fri, Dec 20, 2013 at 3:33 PM, Tianon Gravi [email protected]
wrote:

To further question, how deep does it go? For example, if I have a Dockerfile that uses ONBUILD, then build a new one FROM the result, and then have a third Dockerfile that I FROM that image in, does the third Dockerfile/FROM invoke the ONBUILD clauses too?

Reply to this email directly or view it on GitHub:
#3254 (comment)

• Fixed doc formatting
• Rebased on master
• Added DCO signoff

some comments, if would be nice to check if the string after the onbuild in a valid Dockerfile command, otherwise you can produce a valid image, but that will fail if you try to build from it.

Also we could improve the display, to see what are the build steps, exemple:

from 95e48361ea3c
run echo vv
Uploading context 2.048 kB
Uploading context
Step 0 : from 95e48361ea3c
# Executing 2 build triggers
 ---> Running in ac3c0455ff33
bin
dev
etc
lib
lib64
proc
sbin
sys
tmp
usr
 ---> 5b3a7ca0ac6d
 ---> Running in 66d2f6e20a26
/
 ---> 4462be57741d
 ---> 4462be57741d
Step 1 : run echo vv
 ---> Running in f8e3ce8cecb2
vv
 ---> 14e73ae70d61
Successfully built 14e73ae70d61

I have to guess the first one is a ls and the second a pwd

• Rephrased docs to be more precise on when and how triggers are executed
• Clarify that triggers are not inherited more than one level down

No other supporters or even proper naysayers for ON-BUILD with a hyphen? :)

-1 to the Hyphen.

/cc @tianon this will help with buildpack creation

Yeah not a fan of the hyphen either. For generic on-xxx I was thinking of simply an "ON" instruction

Ok, I suppose that works for me. :)

Taking a look at the docs, I definitely see the potential here. +1

By the way, Travis claims you need to gofmt, and I'd wager he's probably right. ;)

Docs LGTM

I rebased :)

@shykes what about my comments in #3254 (comment)

@vieux I agree checking for validity in advance would be nice, but I think we can keep it for later (presumably if you use ONBUILD you'll need to test your image yourself by building on top of it).

ping @crosbymichael @creack

ping @unclejack

LGTM

@shykes travis failed because gofmt is needed for this code.

@crosbymichael sorry about that. Rebased.

Travis is still saying that integration/buildfile_test.go is not formatted correctly.

I also have a few concerns about the feature as it is right now. Currently it does not display the ONBUILD instructions that are running for a child. It just says # Executing 2 build triggers.

I'm just thinking about security with this so if we can actually see the actually build steps that are going to execution that would be better.

# Executing 2 build triggers
#ADD settings.py /myapp/settings.py
# RUN manage.py syncdb

@shykes Travis is still saying that integration/buildfile_test.go is not formatted correctly.

LGTM

Yay!

Hey @philips @polvi I thought this would make you guys feel better - you're not the only ones waiting 2 months to get merged ;)

@shykes I am afraid there is some problem with inheritance, just created #6445