Provide Alpine agent in release CI

[sxa]

Part of nodejs/node#62764
Splitting out from the initial work done in #4390

Tasks:

• Determine whether to utilise existing decomissioned RHEL8 machine with podman or provision a new server consistent with the other dockerhosts
• Set up the machine with ansible and add to the inventory ansible: add ibm cloud docker host for alpine containers #4414
• Add xz to the alpine dockerfiles (Needed for release CI but not test) Add xz to alpine containers which is required by release machines #4422
• Ensure that the generated tarballs - and the top level directory within them - are not just called node-vXX.YY.Z-linux-x64 as that does not identify it as alpine and will likely result in a race condition when pushing the files to node-www. Proposal in comment below.
• Add the firewall rules to allow the new machine to push to node-www
• Enable in the iojs+release job
• Update expected assets in ansible/www-standalone/tools/promote/expected_assets ansible: add alpine/musl builds to expected assets #4428
• Clear up iojs+release-sxaalpinetest workspaces on Alpine and rhel8-x64-release nodes (Possibly just release-digitalocean-rhel8-x64-1)

[sxa]

On the "generated tarball name" topic, passing VARIATION=musl to make looks like it will do the right thing in terms of making the tarball name and top level directory have linux-x64-musl in it. We'll need to decide on whether to modify the existing linux section to pass that in (blank by default) or have a new section in the iojs+release job for Alpine which only differs by that extra variable.

[richardlau]

On the "generated tarball name" topic, passing VARIATION=musl to make looks like it will do the right thing in terms of making the tarball name and top level directory have linux-x64-musl in it. We'll need to decide on whether to modify the existing linux section to pass that in (blank by default) or have a new section in the iojs+release job for Alpine which only differs by that extra variable.

If modifying the existing section we'd need to be careful that "blank by default" doesn't result (for the usual Linux x64 builds) in e.g. linux-x64-.tar.* (i.e. an empty suffix).

[sxa]

we'd need to be careful that "blank by default" doesn't result (for the usual Linux x64 builds) in e.g. linux-x64-.tar.* (i.e. an empty suffix).

Looks ok based on a quick test 👍🏻

[sxa]

I've floated a discussion with the release WG to see if anyone there (as the users) would have a strong feeling on it, but otherwise we can progress this as a Build WG item.

[sxa]

Proposed diff to the script fragment used for Linux:

***************
*** 26,31 ****
--- 26,37 ----
    RELEASE_URLBASE=https://nodejs.org/download/rc/
  fi
  
+ if [ "${nodes}" = "alpine-x64-release" ]; then
+   VARIATION="musl"
+ else
+   VARIATION=""
+ fi
+ 
  # Ancient and probably needs to be removed? See https://github.com/nodejs/build/pull/2290#issuecomment-615179257
  #
  # # manually force all docker builds to be "custom" / "experimental", also forced
***************
*** 63,68 ****
--- 69,75 ----
    CUSTOMTAG=\"$CUSTOMTAG\" \
    RELEASE_URLBASE=\"$RELEASE_URLBASE\" \
    CONFIG_FLAGS=\"$CONFIG_FLAGS\" \
+   VARIATION=\"$VARIATION\"
  "
  
  if [[ "$NODE_LABELS" =~ (pi1-docker|docker-armv7) ]]; then

I believe the check on the $nodes variable should be safe here.

The iojs+release job will also need the axis for alpine-x64-release enabled and alpine-x64-release added to the regular expression for selecting that script fragment. Noting that while I've used alpine-x64-release we could use musl-x64-release or musl-x64-release as the label if that was preferred, however we used platform-alpine as the team name over musl so I think that's probably the best approach here even though the more generic musl will be in the file names.

Test build with these changes is at https://ci-release.nodejs.org/job/iojs+release-sxaalpinetest/826/

[richardlau]

We'll need to decide which release lines to enable (all at once or gradually?). If it is not all at once we'll need a VersionSelectorScript entry.

[MikeMcC399]

Is there any risk to enabling all at once?

https://unofficial-builds.nodejs.org/ would still be providing builds in parallel, I imagine.

[sxa]

We'll need to decide which release lines to enable (all at once or gradually?). If it is not all at once we'll need a VersionSelectorScript entry.

Given that we've been testing Alpine in the main CI from ages I was probably going to enable it for all and let it show up as and when new updates get produced. Seems the easiest option but we can discuss in the Build WG call.

[richardlau]

Just remembered we'll need to update the expected assets in https://github.com/nodejs/build/tree/main/ansible/www-standalone/tools/promote/expected_assets for each release line we'll expect the additional package(s) in (and remember to deploy the updated expected assets onto the machine).

[sxa]

Slightly odd - I'm getting this in the logs:

19:12:37 gzip -c -f -9 node-v24.19.1-test9e39360a09370d47d781c9c24192c264ec996a99-linux-x64-musl.tar > node-v24.19.1-test9e39360a09370d47d781c9c24192c264ec996a99-linux-x64-musl.tar.gz
19:13:07 xz -c -f -9e node-v24.19.1-test9e39360a09370d47d781c9c24192c264ec996a99-linux-x64-musl.tar > node-v24.19.1-test9e39360a09370d47d781c9c24192c264ec996a99-linux-x64-musl.tar.xz
19:15:17 rm -f node-v24.19.1-test9e39360a09370d47d781c9c24192c264ec996a99-linux-x64-musl.tar
19:15:17 ssh node-www "mkdir -p nodejs/custom/v24.19.1-test9e39360a09370d47d781c9c24192c264ec996a99"
19:15:21 chmod 664 node-v24.19.1-test9e39360a09370d47d781c9c24192c264ec996a99-linux-x64.tar.gz
19:15:21 chmod: node-v24.19.1-test9e39360a09370d47d781c9c24192c264ec996a99-linux-x64.tar.gz: No such file or directory
19:15:21 make: *** [Makefile:1356: binary-upload] Error 1

Despite the fact that both the gzip and chmod commands in the top level Makefile are referencing $(TARNAME).tar.gz - this was with disttype=test. Will see tomorrow if the same happens in the nightlies.

CORRECTION: The tar-upload target does use $(TARNAME).tar.gz but binary-upload uses $(TARNAME)-$(OSTYPE)-$(ARCH).tar.gz where the code that creates it in the $(BINARYTAR) target uses $(BINARYNAME).tar which already has the VARIATION extension so there's likely the difference that we'll need to account for - not the tar-upload one. I would expect that making binary-upload use $(BINARYNAME).tar is the right approach but I'll leave that til tomorrow pending the results of the nightly builds. If we need to re-disable alpine for any upcoming releases before this is fixed then we can do so.

[richardlau]

I would expect that making binary-upload use $(BINARYNAME).tar is the right approach but I'll leave that til tomorrow pending the results of the nightly builds. If we need to re-disable alpine for any upcoming releases before this is fixed then we can do so.

nodejs/node#65282 looks correct (and safer, see nodejs/node#65282 (comment)). Since it is an actual code change that would need to land for each release line then we'd need to either:

• Only enable the alpine release builds for Node.js >=26 (VersionSelectorScript.groovy) initially after landing build: update binary-upload to use correct tarball name node#65282. Wait the usual "two weeks in current" before cherry-picking/backporting to LTS releases lines and reenabling the alpine release builds there.
• Get agreement from the Release WG to bypass the "two weeks in current" policy and land build: update binary-upload to use correct tarball name node#65282 on the LTS release lines simultaneously with main.

For releasers the important thing is that iojs+release ideally passes. It would not be a good state if the alpine axis fails.

If we don't get the change into all release lines at the same time we'd have to potentially split #4428 consistent with nodejs/node#65282 and VersionSelectorScript.groovy.