[Mearman]

A job on this fleet that calls actions/setup-node with node-version-file and engines.node >=26 (resolved to 26.12.1) downloads the 26.12.1 linux-arm64 tarball from actions/node-versions into every ephemeral pod, then extracts and caches it. Observed on 2026-10-28 on cold pods of a private repository's CI: about 131 s for the download at roughly 0.2 MB/s (one job took 31 s), the largest remaining part of a job of a few hundred seconds. One observation on one fleet, not a benchmark.

The reference tool-cache image for Node.js already exists for 24.21.0, so this publishes 26.12.1 from the same Dockerfile. A matrix entry of publish-tool-images.yml can now carry a version, which reaches the Dockerfile through its own ARG <TOOL>_VERSION; an entry without one still builds the default. Both versions are tags of github-runner-toolcache-node, and the digest artifacts now carry the version so two versions of one image cannot collide. A profile that names the image as a capability gets node/26.12.1/<arch> and <arch>.complete in its tool cache, and setup-node uses it for any range 26.12.1 satisfies unless check-latest is set. Bumping is a new version in both matrices; the README says so.

I also dropped apk add from the Node.js fetch stage. The base image's busybox already has wget, tar with xz and sha256sum, so the image build runs no package manager, and the archive is still checked against the release's SHASUMS256.txt before it is unpacked. That changes the recipe for 24.21.0 too, but not its output, and a published tag is never rebuilt.

Checked locally: the 26.12.1 tarballs' SHA-256 for linux-x64 and linux-arm64 against nodejs.org's SHASUMS256.txt (the build fails otherwise); a build of both architectures (arm64 natively, amd64 under emulation), laid out as node/26.12.1/{arm64,x64} with the .complete marker beside it, 4744 files; tests/unit/test_tool_images_workflow.py, which fails on a reintroduced apk add and on shared artifact names (mutation-checked); actionlint, shellcheck, hadolint and yamllint on the changed files. I cannot run the publish workflow without pushing images.

tests/capabilities/run.sh passed in this PR's Capabilities in kind job on 236e117, which is the quiet host: both Node.js versions in the pod's tool cache, @actions/tool-cache finding each by its major version, and the rest of the script. It did not pass locally. On my laptop (a loaded Colima VM, 2 CPUs, 4 GB) it ran seven times and none of the runs reached its Node.js assertions: a Docker Hub DNS timeout, my python3 lacking ansible and then PyYAML, kind passing a loopback HTTPS_PROXY into a node that cannot reach it (busybox, then the runner image), a chart fetch failure, and finally No space left on device in the VM. The first CI run failed on my own assertion: Node.js 26 links libatomic.so.1, which the stock runner image lacks, so the test now checks the second version's directory, marker, executable and tool-cache lookup without running its node. The fleet's own runner image does run Node.js 26 (setup-node downloaded the same tarball on those pods and the job passed); Its arm64 build has libatomic1 installed (read from the image); The amd64 build has it too (read on 2026-10-28 from a throwaway container of ghcr.io/exadev/github-runner:latest on the amd64 node: /lib/x86_64-linux-gnu/libatomic.so.1).

Recovery in kind failed on this branch twice and also fails on main (workflow_dispatch run 40752458235, same digest in the same error), so it is not caused by this change. ubuntu-latest is now ubuntu-26.04, and kind load of the pulled busybox:1.36 index fails in ctr images import --all-platforms with content digest ... not found. I assume the cause is that the runner's Docker keeps pulled images as multi-platform indexes in the containerd store, but I did not look at the store itself. 236e117 builds the stand-in pod image from the base image instead of loading the pulled one, and the job passes with it.

Order: merge, run gh workflow run publish-tool-images.yml, make the new github-runner-toolcache-node tag public if the package needs it, and take the digest from the run summary into the fleet's capability (ExaDev/github-runner-fleet#54).