The shared toolcache from 0df4a84 was mounted on /opt/acttoolcache,
but actions/setup-* writes new tools to AGENT_TOOLSDIRECTORY
(=/opt/hostedtoolcache in catthehacker images), so the cache never
persisted across jobs. Combined with no Node 22 baked in and yarn
cache evictions on the runner artifactcache, an e2e job that used
to finish in ~3min ballooned to 11+min when actions/cache restore
silently failed and yarn install fell back to the npm registry over
the host's WireGuard tunnel.
- docker-compose.yml + .env.example: rename volume
forgejo-stack-acttoolcache → forgejo-stack-hostedtoolcache, mount
at /opt/hostedtoolcache so setup-node downloads actually persist.
Update valid_volumes allow-list.
- runner-image/Dockerfile: bake Node 22.22.3 at
/opt/hostedtoolcache/node/22.22.3/x64 with the .complete sentinel
so setup-node@v4 finds it locally and skips the ~30s nodejs.org
download per job. Set YARN_CACHE_FOLDER=/opt/forgejo-stack/yarn-cache
and pre-warm it via an opt-in cache-seed/ directory — drop the
consumer repo's yarn.lock + package.json before build and the
entire yarn cache for that lockfile ships in the image, immune to
artifactcache flakiness.
- setup.sh: seed the hostedtoolcache volume explicitly from the
built job image. Docker only auto-initialises a named volume from
the *first* container that mounts it, and runner-1 (forgejo/runner:6)
has no baked toolcache — without explicit seeding, the empty
volume would shadow Node 22 in every job container.
Verified: post-fix Run #97 quick job is 24s (vs ~37-1m4s pre-fix);
yarn install drops from 678s back to 2.69s; setup-node logs
"Found in cache @ /opt/hostedtoolcache/node/22.22.3/x64" instead
of "Acquiring 22.22.3 - x64 from github.com/...".
Existing installations: `docker volume rm forgejo-stack-acttoolcache`
to remove the now-orphaned old volume after pulling.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
e6f9f1f9f9