Using tagged upstreams is a good idea as it puts you in control of forcing an upgrade.

Best combo is to pin to a specific tag, that you periodically update to the latest stable release, and also allow overriding via a build arg. Anyone who wants the bleeding edge, say for a CI server, can run a build with “latest” as the tag arg.

The Python ones seem to be rebuilt much more frequently (last update was 10 days ago). This is perhaps because it depends on pip which has frequent releases.

We check once a day to see if the upstream repo has been updated and build our base images. I have used versions of this with clients. https://github.com/boxboat/auto-dockerfile

This is not true. The images are rebuilt automatically when base images are updated.

What is the source for that? When I looked into this before, I wasn't able to find anything in the documentation stating this would happen.

Here's the official Node.JS image from a couple years ago, for example...

  $ sudo docker inspect node:6.1 | grep 'Z"'
         "Created": "2016-05-06T21:57:54.091444751Z",
             "LastTagTime": "0001-01-01T00:00:00Z"

Node 6.1.0 was released on May 6 2016, it looks to me like the image was never changed after that? And if I run `ls -lah /var/lib/dpkg/info/*.list` inside the image, I get a modification time of May 3, 2016 on all the files... I tried the "node:10.0" image as well and I see similar behavior.

This is how the official images work.

https://github.com/docker-library/official-images/tree/maste...

Each image has a manifest with all the source repos, tags, what commit to pull from, what arches are supported, etc.

As long as the tag is listed in that manifest, it is automatically rebuilt when the base image changes.

Perhaps we’re talking past each other? When I go to https://github.com/docker-library/official-images/blob/maste...

It only is showing the newest version of node 8.16 listed in the manifest file. In other words, if I had an image based off node 8.15, it isn’t going to be updated ever.

So it’s not a matter of just rebuilding regularly, if you aren’t updating your dockerfiles to use newer language versions, you also aren’t going to get system updates.

Edit: I think i do see your point which is that if you are completely up to date on language versions, clearing the build cache every once in a while may still help get a system update if an upstream image is changed in between the release of a new language tag.

Yes, and it is mostly up to the maintainer of the image on how to handle tags. Typically minor patch releases are not kept around once the new patch is out. May be worth filing an issue if this is problematic?