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

Comments

Projects
None yet
@yosifkit
Member

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

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Sep 22, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Mar 22, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Mar 22, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Mar 22, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@mattrobenolt

mattrobenolt Mar 22, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@cap10morgan

cap10morgan Mar 22, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@chorrell

chorrell Mar 22, 2017

Contributor

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

Contributor

chorrell commented Mar 22, 2017

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

@directhex

This comment has been minimized.

Show comment
Hide comment
@directhex

directhex Mar 22, 2017

Contributor

Kill it with fire.

Contributor

directhex commented Mar 22, 2017

Kill it with fire.

@Starefossen

This comment has been minimized.

Show comment
Hide comment
@Starefossen

Starefossen Mar 22, 2017

Contributor

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

Contributor

Starefossen commented Mar 22, 2017

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

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Mar 22, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@LaurentGoderre

LaurentGoderre Mar 23, 2017

I also agree and prefer the example Dockerfile

LaurentGoderre commented Mar 23, 2017

I also agree and prefer the example Dockerfile

@pesho

This comment has been minimized.

Show comment
Hide comment
@pesho

pesho Mar 23, 2017

Contributor

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

Contributor

pesho commented Mar 23, 2017

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

@tracker1

This comment has been minimized.

Show comment
Hide comment
@tracker1

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

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

This comment has been minimized.

Show comment
Hide comment
@carlossg

carlossg Apr 3, 2017

Contributor

I'm 👍 to remove it

Contributor

carlossg commented Apr 3, 2017

I'm 👍 to remove it

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Apr 4, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Apr 19, 2017

Contributor

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

Contributor

cpuguy83 commented Apr 19, 2017

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

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Apr 21, 2017

Member

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

Member

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

Remove onbuild images
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

Remove onbuild images
The Docker project would like us to deprecate those:
docker-library/official-images#2076
@tianon

This comment has been minimized.

Show comment
Hide comment
Member

tianon commented May 18, 2017

carlossg added a commit to carlossg/docker-maven that referenced this issue Jun 15, 2017

@tianon tianon referenced this issue Jul 6, 2017

Closed

`onbuild` variant #13

styfle added a commit to styfle/docker-node that referenced this issue Jul 19, 2017

Update readme to deprecate ONBUILD variable
It looks like the ONBUILD variant was deprecated in docker-library/official-images#2076
This change adds one line to the README.md file.
@sumtiogo

This comment has been minimized.

Show comment
Hide comment
@sumtiogo

sumtiogo Jul 27, 2017

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.

sumtiogo commented Jul 27, 2017

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.

zakame added a commit to zakame/docker-library-docs that referenced this issue Jul 28, 2017

Add example on how to make an onbuild image for Perl
Instead of providing an `onbuild` variant, show to the user how it is
created instead, by example.

See Perl/docker-perl#13 and
docker-library/official-images#2076

zakame added a commit to zakame/docker-library-docs that referenced this issue Jul 28, 2017

Add example on how to make an onbuild image for Perl
Instead of providing an `onbuild` variant, show to the user how it is
created instead, by example.

See Perl/docker-perl#13 and
docker-library/official-images#2076

@0xcaff 0xcaff referenced this issue Dec 3, 2017

Merged

Updated Dockerfile #576

3 of 9 tasks complete

@tianon tianon referenced this issue Jan 4, 2018

Open

Create a new official image for fluentd #3724

4 of 9 tasks complete

@Silex Silex referenced this issue Mar 16, 2018

Merged

Refactor images #24

pzelnip added a commit to bambora/dev.na.bambora.com that referenced this issue Apr 16, 2018

WEB-1179 fix Dockerfile for local dev
As it turns out the base docker image used (the "onbuild" variant) is
now deprecated and recommended to not be used.  See:

https://hub.docker.com/_/ruby/
docker-library/official-images#2076

I found with the 2.3-onbuild image I'd get failure to even complete
the first line of the Dockerfile on a docker build.  This replaces
the onbuild image with a proper Ruby 2.3 image and modifies the
instructions for running as appropriate.

pzelnip added a commit to bambora/dev.na.bambora.com that referenced this issue Apr 16, 2018

WEB-1179 fix Dockerfile for local dev
As it turns out the base docker image used (the "onbuild" variant) is
now deprecated and recommended to not be used.  See:

https://hub.docker.com/_/ruby/
docker-library/official-images#2076

I found with the 2.3-onbuild image I'd get failure to even complete
the first line of the Dockerfile on a docker build.  This replaces
the onbuild image with a proper Ruby 2.3 image and modifies the
instructions for running as appropriate.

@SimenB SimenB referenced this issue Apr 25, 2018

Merged

Update node.js #696

@rdebath

This comment has been minimized.

Show comment
Hide comment
@rdebath

rdebath May 4, 2018

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

rdebath commented May 4, 2018

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

loomchild added a commit to puffinrocks/puffin that referenced this issue May 10, 2018

Drop -onbuild Python base image, fix on 3.6.4
Docker -onbuild images are deprecated, since they are not fully
dependable
(docker-library/official-images#2076).

I replaced it with a standard image, based on
docker-library/python#196

I also fixed the version on 3.6.4, since there's an issue with 3.6.5
(https://stackoverflow.com/questions/49627807/cryptacular-is-broken).

Closes #20.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment