Official-images: [Proposal] Deprecate `onbuild` tags

[yosifkit]

From our docs description of onbuild:

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 docker/docker#5714, docker/docker#8240, docker/docker#11917).

Users are often wanting customization on the order of the onbuild directives (some examples in this search). Since we recommend them only to get started, I think it would be better to just provide an example Dockerfile in the docs for these images.

The following are the onbuild images:

$ bashbrew list --all --uniq | grep onbuild
clojure:onbuild
clojure:alpine-onbuild
django:python3-onbuild
django:python2-onbuild
erlang:19.0.3-onbuild
erlang:18.3.4.3-onbuild
golang:1.6.3-onbuild
golang:1.7.0-onbuild
iojs:1.8.4-onbuild
iojs:2.5.0-onbuild
iojs:3.3.0-onbuild
jruby:9-onbuild
jruby:1.7-onbuild
maven:3.3.9-jdk-7-onbuild
maven:3.3.9-jdk-7-onbuild-alpine
maven:3.3.9-jdk-8-onbuild
maven:3.3.9-jdk-8-onbuild-alpine
maven:3.3.9-jdk-9-onbuild
mono:3.10.0-onbuild
mono:3.12.1-onbuild
mono:3.8.0-onbuild
mono:4.0.5.1-onbuild
mono:4.2.1.102-onbuild
mono:4.2.2.30-onbuild
mono:4.2.3.4-onbuild
mono:4.2.4.4-onbuild
mono:4.4.0.182-onbuild
mono:4.4.1.0-onbuild
mono:4.4.2.11-onbuild
node:0.10.46-onbuild
node:0.12.15-onbuild
node:4.5.0-onbuild
node:5.12.0-onbuild
node:6.4.0-onbuild
pypy:2-5.3.1-onbuild
pypy:3-5.2.0-alpha1-onbuild
python:2.7.12-onbuild
python:3.3.6-onbuild
python:3.4.5-onbuild
python:3.5.2-onbuild
python:3.6.0a3-onbuild
rails:onbuild
ruby:2.1.10-onbuild
ruby:2.2.5-onbuild
ruby:2.3.1-onbuild
sentry:8.6.0-onbuild
sentry:8.7.0-onbuild

[tianon]

I'm +1, but I think we should also probably poke the maintainers of each of these images to see what their thoughts are as well. :+1:

[tianon]

I'm still +1 on this after all this time (probably more strongly than before) -- let's cc some maintainers today to see if we get any strong, well-reasoned dissent. I've only seen the onbuild variants cause confusion (especially around what to do when they aren't sufficient), so I think we should axe them.

[tianon]

$ bashbrew list --all --uniq | grep onbuild | cut -d: -f1 | sort -u
clojure
django
erlang
golang
haxe
iojs
jruby
maven
mono
node
pypy
python
rails
ruby
sentry

[tianon]

• clojure:onbuild, cc @Quantisan @cap10morgan
• erlang:onbuild, cc @c0b
• haxe:onbuild, cc @andyli
• jruby:onbuild, cc @cpuguy83
• maven:onbuild, cc @carlossg
• mono:onbuild, cc @directhex
• node:onbuild, cc @chorrell @Starefossen @hmalphettes @jlmitch5 @pesho @retrohacker @mikeal @LaurentGoderre
• sentry:onbuild, cc @mattrobenolt

Please give https://github.com/docker-library/official-images/issues/2076#issue-172237857 a look and decide whether you have a strong opinion against this. If we don't get good arguments for keeping them (preferably with examples where they've been helpful, but not required), we'll be deprecating onbuild variants.

Concretely, this will mean updating the text in https://github.com/docker-library/docs/blob/20177c318c17c228ae44395feba8fe14f8aa6a3d/.template-helpers/variant-onbuild.md to note that they're deprecated and strongly discouraged, and removing the tags themselves from the "Supported" list of each image over time.

[mattrobenolt]

For Sentry, onbuild is used as the base for https://github.com/getsentry/onpremise

Granted, we could shuffle things around a bit, but I think Sentry's usage of onbuild is a much different story than those of say, python or node, etc. I'm open to accommodating if you want to nuke this concept entirely though. I feel it'd make sense to leave it up to the individual project though.

[cap10morgan]

I am 👍 on getting rid of onbuild variants. They provide so little value for such a short time (of an application's lifecycle) and so easily lead to frustration with their inflexibility that I think they do more harm than good in general.

[chorrell]

I'm 👍 with deprecating onbuild and just providing some example Dockerfiles instead.

[directhex]

Kill it with fire.

[Starefossen]

This is very fine with me 👍🏼 Will solve some common problems!

[tianon]

@mattrobenolt oh, neat! I'm happy to have sentry be an outlier in this case, since you're seeing real value from it (from a functional perspective, that will simply mean we need to leave https://github.com/docker-library/docs/blob/20177c318c17c228ae44395feba8fe14f8aa6a3d/sentry/variant-onbuild.md alone :smile: :+1:)

As far as general policy goes, I think the consensus seems to be in line with what @yosifkit and I have observed, so if we do go forward with this, we'll simply have a policy that ONBUILD is discouraged and create exceptions for good use cases like sentry's. :+1:

[LaurentGoderre]

I also agree and prefer the example Dockerfile

[pesho]

+1 for deprecating -onbuild. A minimal example Dockerfile would better accomplish its purpose, without sacrificing extensibility.

[tracker1]

Kind of sad to see the move to push the -onbuild images out... They've been great, for me in terms of getting a project up/deployed quickly in, for example dokku. I mean, yeah, I can just put all the instructions that would be in -onbuild into the Dockerfile, beyond that, my build is usually a little more complex... that said, the onbuild images have been greatly appreciated.

[carlossg]

I'm 👍 to remove it

[tianon]

@tracker1 I agree that they're useful, but the maintenance burden (in terms of user reports / education) is too high to justify continuing (at this level) -- I'd be all for a separate project incorporating a set of useful ONBUILD-using versions of the official images for common use cases (so that it can be more focused on the specifics of ONBUILD) :+1:

[cpuguy83]

In 17.05, ONBUILD should be slightly less useless now that you can use ARG before FROM

[tianon]

@cpuguy83 yeah, that's neat! Although for official images, it doesn't solve the maintainability problem, since we'll still have to explain to users how to use it repeatedly, or update it with hanky things like ONBUILD_EXTRA_RUN and ONBUILD RUN [ -z "$ONBUILD_EXTRA_RUN" ] || eval "$ONBUILD_EXTRA_RUN" to try and cover all the ways folks might use it.

So even with that addition, I'm still of the opinion that for the official images, it makes sense for us to stick to providing a simple template in the image description for repository usage, and allow for some downstream project to take on the maintenance of ONBUILD variants that do "magic". :+1:

[tianon]

https://github.com/docker-library/docs/pull/911 :+1:

[sumtiogo]

onbuild helps people easy to use if they don't need customization.
example Dockerfile helps those who want to customize.
I think they are both good for people using docker.
Image maintainer could always refuse to customize the onbuild image because users always could customize by themselves.

People need customization is not the reason to deprecated onbuild; Lack of willing to maintain is.

[rdebath]

I'm just learning how docker works so this may be done elsewhere. But ...

It strikes me that what you actually wanted to support here was a "default" docker file for the child. The idea being that if the child's docker file consists of just the single FROM command it's completely replaced by a named file from the parent. If the user who's building the child puts anything else in their Dockerfile they have taken control. (NB: ARG 'commands' might be needed too).