Concise Output

[nebhale]

Previously the output of the detect phase was way too verbose printing the id and version of every buildpack and whether it passed or failed. Given large buildpack groups this was a large block of text that was difficult to visually parse for useful information.

A recent change to the output then simplified it to describe only the number of buildpacks that were participating in the build phase, but removed their id and version. This version of the output ended up being too terse, removing the genuinely useful information of what buildpacks were manipulating your application.

This change splits the difference between the two previous attempts. It prints the number of buildpacks participating out of the number of options (implying that the others failed or skipped) and then prints the id and version of each of the participating buildpacks. The detailed information about the non-participating buildpacks is still useful in some circumstances, and should be added back once logging levels are implemented in the lifecycle. A recommendation would be the current output at Info, and full output at Debug.

Example output:

===> DETECTING
[detector] 8 of 35 buildpacks participating
[detector] io.pivotal.openjdk                   1.0.7-2-gee0dfc5
[detector] io.pivotal.jvmapplication            1.0.24
[detector] io.pivotal.tomcat                    1.0.33
[detector] io.pivotal.springboot                1.0.29
[detector] io.pivotal.distzip                   1.0.29
[detector] io.pivotal.clientcertificatemapper   1.0.31
[detector] io.pivotal.containersecurityprovider 1.0.27
[detector] io.pivotal.springautoreconfiguration 1.0.33

[jkutner]

I like this better than what I have in #183. But I'm not sure if I'm keen on the of <X>. Does that number include all buildpacks in all groups? I'm not sure how useful it is that way. I'm also wondering how often this will print 1 of 1. Could it be only X buildpacks participating?

[nebhale]

@jkutner it corresponds to done here. It's a shorthand way of indicating that there were some buildpacks that chose not to participate within the winning group. I don't think it's important to be pedantically accurate as a --verbose flag would expose all groups and all buildpack statuses.

On our side, it'll never be 1 of 1 as we don't have any situation where we use only a single buildpack (not even Golang).

[jkutner]

I guess the situation i'm thinking of is this: a Ruby program who wants to build a Rails app with the Heroku builder. They see:

===> DETECTING
[detector] 1 of 9 buildpacks participating
[detector] heroku/ruby                   1.0.0

The "9" here is extraneous because those other buildpacks are Java, PHP, Go, etc. It might even confuse people ("I thought i was just using the Ruby buildpack?").

The problem, IMO, is that it leaks the underlying implementation to the user. A user doesn't need to know or care how many buildpacks are in a builder--they only need it to work and build their image.

If the --verbose flag would expose all groups and all buildpack statuses, do we need to show this in the info logs?

FYI: not going to die on this hill. I generally like you're change here.

[hone]

Overall I like this change. Do we just build our builders differently of what we put them in? i.e. do you have a Java or Go as separate builders?

[nebhale]

@hone Ah, that must be the difference! We have multiple languages in the same builder, but they're all handled as separate groups. So in your case, you'd likely see a single "1 of 1" for whatever language you picked.

[jkutner]

@nebhale ohhhh, that makes much more sense. Could we add a check, and if len(trial) == len(done) we don't show the of X?

[nebhale]

Sure @jkutner. Elide the whole line or just the of X bit?

[jkutner]

@nebhale elide the whole line. no need to shame the 1 buildpack for being a loner :)