Repository navigation
Provide Alpine agent in release CI #4423
Description
Activity
On the "generated tarball name" topic, passing
VARIATION=muslto make looks like it will do the right thing in terms of making the tarball name and top level directory havelinux-x64-muslin 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 theiojs+releasejob for Alpine which only differs by that extra variable.- pinned this issue
on Aug 12, 2026 On the "generated tarball name" topic, passing
VARIATION=muslto make looks like it will do the right thing in terms of making the tarball name and top level directory havelinux-x64-muslin 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 theiojs+releasejob 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).Reacted by Stewart X Addisonwe'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 👍🏻
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.
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) ]]; thenI believe the check on the
$nodesvariable should be safe here.The
iojs+releasejob will also need the axis foralpine-x64-releaseenabled andalpine-x64-releaseadded to the regular expression for selecting that script fragment. Noting that while I've usedalpine-x64-releasewe could usemusl-x64-releaseormusl-x64-releaseas the label if that was preferred, however we used platform-alpine as the team name overmuslso I think that's probably the best approach here even though the more genericmuslwill be in the file names.Test build with these changes is at https://ci-release.nodejs.org/job/iojs+release-sxaalpinetest/826/
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.
Is there any risk to enabling all at once?
https://unofficial-builds.nodejs.org/ would still be providing builds in parallel, I imagine.
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.
Reacted by Richard Lau and Mike McCreadyJust 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).
Reacted by Stewart X AddisonSlightly 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 1Despite the fact that both the
gzipandchmodcommands in the top level Makefile are referencing$(TARNAME).tar.gz- this was withdisttype=test. Will see tomorrow if the same happens in the nightlies.CORRECTION: The
tar-uploadtarget does use$(TARNAME).tar.gzbutbinary-uploaduses$(TARNAME)-$(OSTYPE)-$(ARCH).tar.gzwhere the code that creates it in the$(BINARYTAR)target uses$(BINARYNAME).tarwhich already has the VARIATION extension so there's likely the difference that we'll need to account for - not thetar-uploadone. I would expect that makingbinary-uploaduse$(BINARYNAME).taris 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.I would expect that making
binary-uploaduse$(BINARYNAME).taris 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+releaseideally 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.- Only enable the alpine release builds for Node.js >=26 (
I was just thinking about this before I saw your comment. I feel we can reasonably justify requesting the bypass of "two weeks in current" on the basis that it's not a functional change to the code and is something specifically for the release process.
For now I'll disable alpine in
iojs+releaseagain and I've put 4428 into draft to ensure we don't merge it yet.v24.20.0 released by stealth (i.e. not visible on the web site) on the new machine at https://nodejs.org/dist/v24.20.0/node-v24.20.0-linux-x64-musl.tar.xz
Reacted by Mike McCreadyThat should be good for testing, at least! For docker-node we'd probably want to wait until all supported release lines are available before switching away from unofficial builds.
Reacted by Stewart X Addison and Nick Schonningv26.8.1 is also available: https://nodejs.org/dist/v26.8.1/node-v26.8.1-linux-x64-musl.tar.xz
Since the Alpine agent is working I'm going to close this issue. There is still a PR to enable this for v22 but that is independent of the issue of creating the machine :-)
- unpinned this issue
on Aug 27, 2026
Part of nodejs/node#62764
Splitting out from the initial work done in #4390
Tasks:
xzto the alpine dockerfiles (Needed for release CI but not test) Addxzto alpine containers which is required by release machines #4422ansible/www-standalone/tools/promote/expected_assetsansible: add alpine/musl builds to expected assets #4428iojs+release-sxaalpinetestworkspaces on Alpine and rhel8-x64-release nodes (Possibly just release-digitalocean-rhel8-x64-1)