Post images to docker hub automatically upon release

[bbangert]

What is the problem this feature will solve?

A security fix went out for LTS in 18.18.2, but no corresponding images were posted to docker hub.

What is the feature you are proposing to solve the problem?

Images should be updated and posted automatically to docker hub when new versions are released.

What alternatives have you considered?

No response

[meyfa]

They are, it just takes a while. See: nodejs/docker-node#1976 (comment)

In my opinion, it feels like too much time. The vulnerabilities are announced on release, but Docker users, which are probably the majority of enterprise Node.js users, have to wait to fix them. After the linked PR is merged, it will have to be merged again at Docker's own repository.

I wonder if it would be possible to adapt the security release process somehow; perhaps by preparing the required builds beforehand?

[tniessen]

I wonder if it would be possible to adapt the security release process somehow; perhaps by preparing the required builds beforehand?

Are you referring to building the Node.js binaries or the Docker images? We do wait until all official release binaries have been built, however, I believe that some unofficial builds (unofficial-builds.nodejs.org) may be available at a later time only. See also Supported platforms: Strategy.

[meyfa]

I'm referring to the Node.js binaries, as I'm aware that Docker Inc. is building the images themselves, and Node.js has no control over the speed of that.

I think the issue here is that musl/Alpine Linux, one of the Docker image flavors, is classified as Experimental tier. This seems to cause the delay, as it is considered an unofficial binary and is built only after the security release is made. Yet, docker-node need it to exist so they can create the PR to Docker's official images repo.

[tniessen]

I think we do test against Alpine through Jenkins CI, and given that Alpine-based images are quite popular, I can only assume that support for Node.js on musl is rather stable. Nevertheless, I am not sure whether or not it is realistic to upgrade musl to Tier 2 or so. cc @nodejs/build

[bnoordhuis]

I don't think there are that many maintainers that run musl-based systems, it's experimental for a reason.

The phrase "enterprise users" was invoked a few comments up. Maybe they want to sponsor the project or individual maintainers to work on musl compatibility?

[meyfa]

As far as I can see, Node.js already runs great on musl-based systems and has done so for quite a while. I'm also pretty sure many Node.js contributors deploy it via Docker, and in that case, it's extremely likely that they use Alpine. There seem to be few issues raised about compatibility problems. What exactly is missing for it to be considered stable?

[bnoordhuis]

To get to tier 2 there should be at least one or two people who respond in a timely and adequate fashion to any issues that pop up. At that point it effectively becomes a job and it's not only reasonable but moral to pay people for their time.

[mhio]

Experimental: May not compile or test suite may not pass. The core team does not create releases for these platforms. Test failures on experimental platforms do not block releases. Contributions to improve support for these platforms are welcome.

Tying release of all node docker images to the above condition seems unreliable.

Btw, it looks like unofficial builds turned up 14-Oct-2023 03:34 (TZ?) and version updates merged but the docker-library changes are still waiting for approval.

This dist releases were first available be 13-Oct-2023 14:03 and arm by 13-Oct-2023 18:05. Again, I'm unsure of the dist/unofficial-builds timezone as the docker-node commit that picked these up doesn't line up.

[shaneog]

Tying release of all node docker images to the above condition seems unreliable.

100% this.

I understand that this release fell on/just before a weekend, but there has to be some way of improving the release speed of official Docker images.

[bnoordhuis]

Be the change you want to see. Either step forward and commit to maintaining the musl port (expect a 3 to 6 months trial period before promotion to tier 2) or chip in by sponsoring existing maintainers.

I'll leave this issue open for a week or two. If nothing has happened by then, that speaks volumes and I'll go ahead and close it.

[mhio]

The other "or" is to seperate the experimental builds from the image release work flow. That probably doubles the approvals for each release, for both the node and docker side, but I feel the rest of that process would automation tasks? On the surface it seems more achievable than put up or cough up.