Live data from Hacker News

Node Docker image broken

github.com

11–20 of 25 posts

Re: Node Docker image broken

#11
post #10
post #2

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).

huh? so like, don't use open source libraries?

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?

Re: Node Docker image broken

#12
post #10
post #2

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).

huh? so like, don't use open source libraries?

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.

Re: Node Docker image broken

#13
Was this untested or something?

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.)

Re: Node Docker image broken

#14
post #6

well i mean it's broken if you use yarn. which isn't a standard part of node, so like, not really?

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).

Re: Node Docker image broken

#15
post #8
post #7

Never ever use :latest unless its in your docker-compose DEV file. Try to treat docker images like you would dependencies. We always lock down to specific versions, but we also use a self hosted docker mirror to cache everything anyway.

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.

You subscribe to notifications about security updates, but never blindly accept them.

Re: Node Docker image broken

#16
post #5
post #4

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

Latest should only be used for hackery / development, but please fix it to a stable version before release. 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?

> Overwriting tags should honestly not be possible, ever.

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?

Re: Node Docker image broken

#17
post #5
post #4

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

Latest should only be used for hackery / development, but please fix it to a stable version before release. 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?

> 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

Re: Node Docker image broken

#19
post #10

Earlier quoted context omitted.

huh? so like, don't use open source libraries?

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 whic…

> host that version in a location you control

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.)

Re: Node Docker image broken

#20
post #8
post #7

Never ever use :latest unless its in your docker-compose DEV file. Try to treat docker images like you would dependencies. We always lock down to specific versions, but we also use a self hosted docker mirror to cache everything anyway.

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.

Security updates should be vetted and not auto-accepted.

There's no problem here.

Post reply on HN