Ah yes, this happens from time to time when you use somebody else's
repositories with somebody else's package retention. That's why production
should only use repositories that change in ways that are predictable to you
(OS upstream, your own, and usually nothing else).
Are you implying that you cannot use others' code unless you download it from
random places from the internets? That the others' code is fundamentally
different from your code and thus cannot be hosted from your own repository?
That's not what the OP is trying to say, though they have a hard time coming out and saying it, and their reply to you doesn't help matters.
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 mean, up until last year someone could permanently depublish entire packages from certain package managers without restriction. No amount of hash-refs are going to ensure you have the right package if it just doesn't exist anymore.
I think availability is exactly what dozzie was getting at by specifying 'production'.
You want your production systems to be robust, not reliable at the whims of half a dozen different ecosystems all with different policies, procedures, humans, support agreements, etc. (This is without even touching on infrastructure availability.)
This is one of the reasons I never use the latest version of any docker image, so I don’t repeat my constant struggles with npm packages breaking on minor version changes
Edit:
I see they were overwriting current tags.... well that’s even worse
If secrets are published, there is no way to ‘unpublish’ them. Consider them burned.
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.
“Published” doesn’t always mean “public.” You can publish something to an internal company repo, and still want to remove it in case an unscrupulous coworker ever joins and digs through your history.
Also, consider “secrets” in the “Personally Identifiable Information” sense, or the “confidential information shared to you by a third party” sense. If these are published, someone might see them; but the longer they stay published, the more people might see them, so you have an obligation to remove them.
Also, re: reusing a tag, what about having already announced a release version number, and tagging the release with it, only to find out the release is broken? It’s kind of problematic to have to bump the version again when the previous version didn’t even go out to anyone.
I would propose a slightly more relaxed rule: you shouldn’t be able to erase/overwrite a tag once there exist other tags in the repo with creation or signing timestamps newer than those of the targeted tag. So you can overwrite something you just created, but not something that’s “history.”
(An alternative to this would be if tags had nicknames or “object versions”, like in an S3 bucket. If you could have a v1.0.0 “tag” that first pointed to a static v1.0.0+1 ref, and then to a v1.0.0+2 ref, where clients don’t see the static ref tags but can still check them out using some special syntax in combination with the visible tag—and where you can revoke a static ref, but not overwrite it—that’d probably make everyone happy.)
NPM doesn't allow version numbers to be re-used for a new release. (The old drama you might be thinking of was that NPM used to allow packages to be unpublished, which affected a lot of people when someone unpublished their popular module. NPM no longer allows releases to be unpublished after 24 hours.)
It's not standard, true, but it's also not an experimental feature, so one still wouldn't expect them to do wacky things like overwrite tags. I think many people expect version tagged code to not change, unless the developers specifically say they are nightly/experimental (there is a comment to that effect on the issue link).
other labels are mutable too though. That's why this broke for other tags beside latest. Use the hash instead for a hard link, but obviously won't get any security updates.
24 comments
[ 4.8 ms ] story [ 59.9 ms ] threadInstead, 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 think availability is exactly what dozzie was getting at by specifying 'production'.
You want your production systems to be robust, not reliable at the whims of half a dozen different ecosystems all with different policies, procedures, humans, support agreements, etc. (This is without even touching on infrastructure availability.)
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?
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.
Also, consider “secrets” in the “Personally Identifiable Information” sense, or the “confidential information shared to you by a third party” sense. If these are published, someone might see them; but the longer they stay published, the more people might see them, so you have an obligation to remove them.
Also, re: reusing a tag, what about having already announced a release version number, and tagging the release with it, only to find out the release is broken? It’s kind of problematic to have to bump the version again when the previous version didn’t even go out to anyone.
I would propose a slightly more relaxed rule: you shouldn’t be able to erase/overwrite a tag once there exist other tags in the repo with creation or signing timestamps newer than those of the targeted tag. So you can overwrite something you just created, but not something that’s “history.”
(An alternative to this would be if tags had nicknames or “object versions”, like in an S3 bucket. If you could have a v1.0.0 “tag” that first pointed to a static v1.0.0+1 ref, and then to a v1.0.0+2 ref, where clients don’t see the static ref tags but can still check them out using some special syntax in combination with the visible tag—and where you can revoke a static ref, but not overwrite it—that’d probably make everyone happy.)
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
We always lock down to specific versions, but we also use a self hosted docker mirror to cache everything anyway.
There's no problem here.
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.)