Promote Alpine/x64 to tier 2

[sxa]

As per #62764

FYI @nodejs/tsc - I've listed the version associated with the versions of Alpine we currently build against.

[nodejs-github-bot]

Review requested:

• @nodejs/build
• @nodejs/tsc

[MikeMcC399]

This change would be highly desirable from the point of view of the @nodejs/docker team as node:alpine images are being published on Docker official images in the node Docker repo.

The mismatch between "official" status on Docker hub and "Experimental" status in Node.js was raised in 2023 in nodejs/docker-node#2011 by @BethGriggs and remains to this day unresolved.

Confidence would be increased if there were also an Alpine team established, as proposed in nodejs/admin#1065 so that Alpine / musl issues have a group of skilled users available to respond.
Edit: resolved

node:alpine x64 images have been in widespread usage for a number of years.

[aduh95]

What would be the semverness of such change?

[MikeMcC399]

I assume that it would be semver-minor PRs that contain new features and should be released in the next minor version. as a backwards-compatible promotion.

[sxa]

It's not a functional change but an interesting question. I'd say +1 to what Mike said - probably considered semver-minor - even though there are no code changes it's similar to new functionality being added which doesn't affect anything else.

I certainly don't see any reason for it to be considered semver-major, and I am anticipating here that it would apply to all current release lines in order to resolve the complications on the docker-node side.

[mcollina]

lgtm

[Renegade334]

Adding a label for consistency with other build platforms.

[sxa]

For anyone approving this it would be good to have your view on the lifecycle/Alpine version topic from #62764 (comment) - the TL;DR is: should we update the Alpine build level of the release machines (presumably increasing the musl version requirement) during the lifecycle of a node release?

[legendecas]

the TL;DR is: should we update the Alpine build level of the release machines (presumably increasing the musl version requirement) during the lifecycle of a node release?

Given that the actual "versions" column of the Alpine support does not specify the Alpine version, other the kernel and musl version, I'd say "yes".

In addition, there is a note about the platform version support:

node/BUILDING.md

Lines 103 to 105 in bfb2fa7

	Node.js does not support a platform version if a vendor has expired support
	for it. In other words, Node.js does not support running on End-of-Life (EoL)
	platforms. This is true regardless of entries in the table below.

[sxa]

the TL;DR is: should we update the Alpine build level of the release machines (presumably increasing the musl version requirement) during the lifecycle of a node release?

Given that the actual "versions" column of the Alpine support does not specify the Alpine version, other the kernel and musl version, I'd say "yes".

Having thought about it for the last few days I was starting to lean the other way :-) We could take an approach of "bouncing along the floor" of the Alpine versions, updating by one each time a version goes out.

I don't think we have any other platforms where a release has the potential to actively stop working in a customer's environment during a Node lifecycle (as it presumably would if they stayed on the out of support version when we bumped it up in the release CI assuming it would require at least the same version of musl at runtime vs build time which is generally the case for glibc) I'm also in the Build WG so we'd have to keep on top of this in order to make it work so that may be influencing my thoughts on this a little ... I'd say I'm about 60:40 towards keeping it constant at the moment but more input is welcome!