Promote Alpine Linux out of experimental to be a tier 2 platform

What is the problem this feature will solve?

We currently have a significant number of users of Alpine Linux (Linux using musl as its libc implementation). For the direct tarballs from the unofficial builds server there are approximately 1000 downloads per hour for x64 plus about 25 per hour for arm. We do not currently have the figures for the container images on dockerhub but I would expect it to be quite high too.

Given the number of people using this build, I feel there is some justification for releasing this through the normal processes so it is made available in the same timescales as the other tier 1/2 platforms. This would allow security updates to be made available in a timely manner, and also help to reduce any lag visible to customers caused by delays to the release of the container images in the docker-node project which is currently gated by availability of alpine builds (I will also note that there is a proposal to decouple Alpine, but that would not solve the problem of potentially having a delay in getting updates into the hands of our Alpine users)

We should also bear in mind that it is quite likely that many users are not aware that Alpine is in experimental status and do not understand the implications of using this platform in production. While it may be clear to
someone pulling it form the unofficial-builds server - the clue being in the hostname - when viewed on dockerhub it does not look any different to the other platforms which shipped as "official" container images.

Superficially I would hope that it would be a low risk to add Alpine as the Linux/glibc on x64/aarch64 platforms are well-supported and any likely risk would be around its use of musl instead of the GNU libc. I'm not sure if we've ever hit any problems so far because of that difference but I don't recall anything.

Noting that Alpine/x64 is already part of the regular CI testing and therefore failures on that platform will get noticed, but as an experimental platform any CI failures would not currently block a release cycle.

While I'm not considering it as part of this proposal, I will state for background information that we have previously had Alpine/ppc64le and Alpine/s390x container images published by the docker-node project. Alpine/ppc64le was discontinued in the node 22 time frame and I am proposing doing the same for
Alpine/s390x.

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

Promote the Alpine builds from Experimental to Tier 2 so that it is a formal part of the release cycle. This would be at least for the x64 architecture as a minimum, but possibly also arm64.

For this we would want to have some commitment from at least one contributor willing to actively keep up to date with any problems on the platform so in part this is a call for volunteers to be able to handle any failures and ensure that new features can be enabled successfully on the platform. Typically we have found that when problems show up they do get looked at fairly quickly if people spot that the unofficial builds for Alpine are not generated properly. This change would also mean that the environment used in the CI for testing and the build environment would be consistent (Unofficial build environments are not automatically kept in sync with the systems for the equivalent platform in the CI and in fact the compilers used are currently not the same)

We have some Alpine/x64 systems in the CI but would need to evaluate capacity and also add extra systems for arm64 if we chose to promote that Alpine architecture out of experimental status too.

Regardless of whether we choose to promote Alpine, should we perhaps have a github platform team created of interested parties that can be tagged if any issues show up?

What alternatives have you considered?

• Leave it as-is - an experimental platform with no formal support.

• Put more disclaimers on the existing experimental builds which are shipped as "official" container images to dockerhub (either have it more obvious on the dockerhub UI, or build it in such a way that it puts some notice to the console on startup)

• As far as options we also have the choice to do this for just x64 or also arm. I believe Alpine is now quite popular on the desktop for the many developers now using arm Mac desktop systems so this can also be discussed in this issue. I will also note that if we included arm64 we would likely add native arm64 machines in, as opposed to the current cross-compiled one on the unofficial-builds server however I will point out that we do not currently test Alpine/arm in the CI.

FYI @nodejs/build @targos @mcollina and maybe @RafaelGSS who has seen the impacts of Alpine being an experimental platform when the docker images don't always get published quickly.

The current list of platforms and their support category is listed in https://github.com/nodejs/node/blob/main/BUILDING.md#platform-list

A couple of previous discussions on the topic of platform tiers:

• https://github.com/nodejs/node/issues/8265 (Note: From 2016 but referenced the original addition of Alpine to the docker-node project!)
• https://github.com/nodejs/node/issues/43457 (Mostly ref: Smartos)

Comienza con la lista de plataformas de BUILDING.md y, a continuación, relaciona los entornos existentes de Alpine CI y de compilaciones no oficiales descritos en el issue. Determina la capacidad x64 necesaria y la capacidad arm64 opcional, quién se encargará del soporte y los cambios en el proceso de lanzamiento. El trabajo estará terminado cuando los maintainers acuerden el alcance, la asignación de personal y la promoción de Experimental a Tier 2.