Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Deprecate `onbuild` tags #2076

Closed
yosifkit opened this issue Aug 19, 2016 · 20 comments
Closed

[Proposal] Deprecate `onbuild` tags #2076

yosifkit opened this issue Aug 19, 2016 · 20 comments

Comments

@yosifkit
Copy link
Member

@yosifkit yosifkit commented Aug 19, 2016

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
Copy link
Member

@tianon tianon commented Sep 22, 2016

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. 👍

@tianon
Copy link
Member

@tianon tianon commented Mar 22, 2017

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
Copy link
Member

@tianon tianon commented Mar 22, 2017

$ 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
Copy link
Member

@tianon tianon commented Mar 22, 2017

Please give #2076 (comment) 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
Copy link
Contributor

@mattrobenolt mattrobenolt commented Mar 22, 2017

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
Copy link
Contributor

@cap10morgan cap10morgan commented Mar 22, 2017

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
Copy link
Contributor

@chorrell chorrell commented Mar 22, 2017

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

@directhex
Copy link
Contributor

@directhex directhex commented Mar 22, 2017

Kill it with fire.

@Starefossen
Copy link
Contributor

@Starefossen Starefossen commented Mar 22, 2017

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

@tianon
Copy link
Member

@tianon tianon commented Mar 22, 2017

@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 😄 👍)

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. 👍

@LaurentGoderre
Copy link

@LaurentGoderre LaurentGoderre commented Mar 23, 2017

I also agree and prefer the example Dockerfile

@pesho
Copy link
Contributor

@pesho pesho commented Mar 23, 2017

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

@tracker1
Copy link

@tracker1 tracker1 commented Mar 27, 2017

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
Copy link
Contributor

@carlossg carlossg commented Apr 3, 2017

I'm 👍 to remove it

@tianon
Copy link
Member

@tianon tianon commented Apr 4, 2017

@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) 👍

@cpuguy83
Copy link
Contributor

@cpuguy83 cpuguy83 commented Apr 19, 2017

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

@tianon
Copy link
Member

@tianon tianon commented Apr 21, 2017

@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". 👍

akoeplinger added a commit to akoeplinger/docker that referenced this issue May 15, 2017
The Docker project would like us to deprecate those:
docker-library/official-images#2076
akoeplinger added a commit to mono/docker that referenced this issue May 15, 2017
The Docker project would like us to deprecate those:
docker-library/official-images#2076
@tianon
Copy link
Member

@tianon tianon commented May 18, 2017

sachinma added a commit to microsoft/devops-project-samples that referenced this issue Nov 5, 2018
the node:X-onbuild images are deprecated (see docker-library/official-images#2076 for more details)
for the samples just rely on the base image
lag-linaro added a commit to lag-linaro/fluentd-docker-image that referenced this issue Nov 6, 2018
Onbuild images are deemed as 'useful but confusing'.

Rather than produce onbuild images, projects should consider providing
example Dockerfiles for consumers to use for reference.

Almost all official Docker Hub project have removed their onbuilds now.

Ref: docker-library/official-images#2076
Ref: docker-library/docs@3823017

Signed-off-by: Lee Jones <lee.jones@linaro.org>
lag-linaro added a commit to lag-linaro/fluentd-docker-image that referenced this issue Nov 16, 2018
Onbuild images are deemed as 'useful but confusing'.

Rather than produce onbuild images, projects should consider providing
example Dockerfiles for consumers to use for reference.

Almost all official Docker Hub project have removed their onbuilds now.

Ref: docker-library/official-images#2076
Ref: docker-library/docs@3823017

Signed-off-by: Lee Jones <lee.jones@linaro.org>
lag-linaro added a commit to lag-linaro/fluentd-docker-image that referenced this issue Nov 16, 2018
Onbuild images are deemed as 'useful but confusing'.

Rather than produce onbuild images, projects should consider providing
example Dockerfiles for consumers to use for reference.

Almost all official Docker Hub project have removed their onbuilds now.

Ref: docker-library/official-images#2076
Ref: docker-library/docs@3823017

Signed-off-by: Lee Jones <lee.jones@linaro.org>
@yosifkit yosifkit mentioned this issue Feb 6, 2019
8 of 9 tasks complete
andyli added a commit to andyli/docker-library-haxe that referenced this issue Jun 14, 2019
jmlrt added a commit to jmlrt/helm-charts that referenced this issue Sep 25, 2019
docker onbuild have been deprecated in docker-library/official-images#2076 and aren't part of python docker images build since docker-library/python#314.
jmlrt added a commit to jmlrt/helm-charts that referenced this issue Sep 25, 2019
docker onbuild have been deprecated in docker-library/official-images#2076 and aren't part of python docker images build since docker-library/python#314.
jmlrt added a commit to jmlrt/helm-charts that referenced this issue Sep 25, 2019
docker onbuild have been deprecated in docker-library/official-images#2076 and aren't part of python docker images build since docker-library/python#314.
guewen added a commit to guewen/github_pki that referenced this issue Feb 18, 2020
onbuild images [0] are deprecated
go-wrapper [1] is deprecated

[0] docker-library/official-images#2076
[1] docker-library/golang#205
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
15 participants
You can’t perform that action at this time.