We always lock down to specific versions, but we also use a self hosted docker mirror to cache everything anyway.
Edit:
I see they were overwriting current tags.... well that’s even worse
Overwriting tags should honestly not be possible, ever. Node / NPM did that (I think) with one of their versions too. Or was it a npm package?
npm did away with `publish -f` (which would allow that) 4 years ago [1].
[1] http://blog.npmjs.org/post/77758351673/no-more-npm-publish-f
How do you propose to withdraw a release if it’s broken/contains secret keys/etc.? Delete the image itself and leave the tag dangling?
But they mean: images can be removed, but you should not be able to publish 2 different images with the same tag. Then you never know which version of those two you got.
Instead, what they are saying is that you should 1) use a specific version, and 2) host that version in a location you control. This way, updates don't impact your build just because you clamp to the latest (which is a moving target). Also, if they happen to rerelease a tag which worked for a previous build you made and now doesn't, you are still pulling in the same thing.
Basically, if you depend on something, host it yourself. Otherwise, you are asking to be bit by this.
I don’t see how this is implied or required by what the GP said. Lockfiles exist; docker-image and OS package hash-refs exist. Heck, nix exists. Getting what you expected to get is a solved problem, and does not require “host[ing] it yourself.”
Now, availability of your deployment might require hosting it yourself. (Though more often your availability figures will be far worse than those of Docker Hub or launchpad.net.)
I certainly don't see any unit tests as part of the commit that triggered this issue
(Yes, even, or perhaps especially, command line commands should be tested, somehow.)
