3 ms·

This is how the official images work. https://github.com/docker-library/official-images/tree/master/library https://github.com/docker-library/official-images/t

This is how the official images work. https://github.com/docker-library/official-images/tree/master/library 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.

javagram 7y ago
Perhaps we’re talking past each other? When I go to https://github.com/docker-library/official-images/blob/master/library/node 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.
- cpuguy83 7y ago
  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?