question: old tags updates

[costa]

Hello, thank you for your work.

I have a question (after my team member and myself having spent some quality time on discovering this): do you update old tags on docker hub? The tag in question is jruby:9.1.17.0, and I'm wondering if this was some kind of a one-off mistake or am I missing something with the docker images management practices.

Thank you for your reply.

[cpuguy83]

Can you be more specific? What is the issue with 9.1.17.0?

[costa]

that tag was pushed (again) a week ago (the original push was over a year ago) with a different image effectively breaking things (e.g. changed bundler version)

On 31 January 2019 at 20:31:33, Brian Goff (notifications@github.com) wrote:

Can you be more specific? What is the issue with 9.1.17.0?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cpuguy83/docker-jruby/issues/43#issuecomment-459454104, or mute the thread https://github.com/notifications/unsubscribe-auth/AACxOkzcHRjp5Dyo7d23WqbjBT0l3M1Wks5vIzaFgaJpZM4acR8N .

[cpuguy83]

Images get rebuilt when the base image is updated. Since bundler 2.0 was released, I suppose this triggered the breaking change since we just gem install bundler.

@tianon Do you have any guidance here? Thanks 😄

[costa]

thank you for your reply, i didn’t think leaf(patch version)-tagged images were supposed to be rebuilt... i think they shouldn’t still. i mean there should be tags that just don’t move.

On 31 January 2019 at 20:39:52, Brian Goff (notifications@github.com) wrote:

Images get rebuilt when the base image is updated. Since bundler 2.0 was released, I suppose this triggered the breaking change since we just gem install bundler.

@tianon https://github.com/tianon Do you have any guidance here? Thanks 😄

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cpuguy83/docker-jruby/issues/43#issuecomment-459457024, or mute the thread https://github.com/notifications/unsubscribe-auth/AACxOsQ3beJrwMu85D8Lr4dTpoPKVZ-zks5vIzh4gaJpZM4acR8N .

[cpuguy83]

Anything that's in this manifest will be rebuilt automatically: https://github.com/docker-library/official-images/blob/master/library/jruby

This is needed for patching/security purposes.

[tianon]

@cpuguy83 gah, we should've looped you into https://github.com/docker-library/ruby/pull/255, sorry! You'll probably want to take a look at that and see if something similar makes sense for jruby too

[costa]

In my humble opinion, there should be leaf tags which are not ever re-written, only removed (in cases of old age or security issues). As a user, you can always opt-in on updates by using minor (branch) version tags (n.n) — or decide on manual tags switch with patch (leaf) versions (n.n.n). For JRuby, for whatever reasons the versions are named this way, there could be 4 or 5 version tag numbers, of course.

[cpuguy83]

@costa you say that b/c of the bundler issue which can be fixed. It would be downright dangerous to not rebuild on base image updates.

[costa]

You're absolutely right, I'm sharing the common practices of tags/versions management to reduce accidents like that and to reduce users' wasted time. If a leaf tag (commonly it's a patch version) has security issues or whatever, it is removed and replaced with another patch version tag, not updated. So I've learnt that JRuby does not have leaf tags on docker hub, and well, it's a pity.

[tianon]

This is standard practice for all the official images (the specific tagging is up to each image maintainer). See https://github.com/docker-library/official-images#library-definition-files for a bit more details on that.

I think more explicitly what probably needs to happen here is to get https://github.com/cpuguy83/docker-jruby/blob/5209b08ae920ff47a99514d72fc1943508b77e53/9000/jre/Dockerfile#L22 dialed in to use more explicit version numbers (although I'm not sure what the version numbers ought to be).

[headius]

If there is something actionable here, please let us know.