5 Commits
Author SHA1 Message Date
tmu 5a3ee3b8cc 🔀 Merge chore/remove-toolcache-diagnostics into main
CI / release-gate (push) Successful in 2s
CI / build (push) Successful in 18s
CI / publish (push) Skipped
CI / maintain (push) Failing after 14s
2026-09-14 16:07:52 +00:00
tmu 77fb604d7e 📝 Check off the CI Node-baking task
All steps confirmed green in CI ('Found in cache @ /opt/hostedtoolcache/node/
26.8.2/x64', no download). The runner-side force-pull item moves to its own
task, since a changed image under an unchanged tag is still silently ignored.
2026-09-14 16:04:03 +00:00
tmu 1b2b50304e ♻️ Assert the baked tool cache instead of logging it
The diagnostics did their job (missing <version>/<arch>.complete marker, now
written by the image). Replace the noise with a fail-fast assert that names
the same invariant, mirroring the publish job's NPM_TOKEN check: a stale tag
on the runner would otherwise silently reintroduce the per-job download, with
nothing in the repo to catch it.
2026-09-14 16:04:01 +00:00
tmu 048a8870e6 🐛 Write the tool-cache completion marker into the image
CI / release-gate (push) Successful in 3s
CI / build (push) Successful in 39s
CI / publish (push) Skipped
CI / maintain (push) Failing after 15s
setup-node still downloaded although the image carried a perfect
/opt/hostedtoolcache/node/26.8.2/x64/ tree. actions/tool-cache accepts a
cached tool only when the sibling marker <version>/<arch>.complete exists
(tc.find() tests it explicitly); a bare directory is ignored, so the probe
fell through to the download. The marker is what tc.cacheDir() writes after
installing a tool, so the baked entry must create it too.

Job-container diagnostics also confirmed the path was never in question:
RUNNER_TOOL_CACHE=/opt/hostedtoolcache, no mount over it, node -v from the
baked path prints v26.8.2.

CONTRIBUTING records both invariants — the marker, and the fact that a
Dockerfile change keeps the same tag, which forcePull=false can hide.
2026-09-14 15:59:23 +00:00
tmu f0b28c81c0 🔊 Log tool-cache state in the CI build job
CI / release-gate (push) Successful in 2s
CI / build (push) Successful in 40s
CI / publish (push) Skipped
CI / maintain (push) Failing after 42s
The custom image provably carries /opt/hostedtoolcache/node/26.8.2/x64/bin/node
(ls inside the image confirms the layout, modes and the 150 MB binary), yet
setup-node still downloads. So the miss is runtime-only: either the runner is
not running that image or something shadows the path inside the job container.
This step prints mounts, the tool-cache listing, a direct node -v from the
baked path and the RUNNER_* env, then setup-node runs unchanged.

Temporary: remove once the cause is known.
2026-09-14 15:55:52 +00:00
4 changed files with 26 additions and 2 deletions

No files matched your search

+7
View File
@@ -63,6 +63,13 @@ jobs:
- /data/gitea-pages:/data/gitea-pages - /data/gitea-pages:/data/gitea-pages
steps: steps:
- uses: actions/checkout@v4 - uses: actions/checkout@v4
# Fail fast when the job container is not the baked image: a stale
# tag on the runner (`forcePull=false` in its pull log) silently
# reintroduces the per-job download. Mirrors the publish job's
# NPM_TOKEN assert — cheap, and it names the invariant.
- name: Assert the baked tool cache is present
run: |
test -f "/opt/hostedtoolcache/node/$(tr -d '[:space:]' < .node-version)/x64.complete"
- uses: actions/setup-node@v4 - uses: actions/setup-node@v4
with: with:
node-version-file: .node-version node-version-file: .node-version
+5
View File
@@ -102,6 +102,11 @@ Bumping Node is one coordinated change, committed as a unit:
Skipping step 2 fails CI at image pull; skipping step 3 silently reverts to the per-job download. Skipping step 2 fails CI at image pull; skipping step 3 silently reverts to the per-job download.
Two invariants the image must satisfy for the probe to hit, both easy to break:
- **The `x64.complete` marker.** `actions/tool-cache` accepts a cached tool only when `<version>/<arch>.complete` exists next to the directory (`tc.find()` checks it); a plausible-looking `node/<version>/x64/` alone is ignored and the download happens anyway. See the comment in [docker/Dockerfile](./docker/Dockerfile).
- **Tag freshness.** The tag encodes only the Node version, so a Dockerfile change (like the marker above) produces _new content under an unchanged tag_. `act_runner` skips the pull when a tag of that name already exists locally (`forcePull=false` in the job log), so the runner must either force-pull (`force_pull` under `container:` in its `config.yaml`, if the installed version has it) or have the tag removed on the runner host (`docker rmi gitea.e1nsnull.de/tmu/act-ci:<version>`) after any image change. Symptom of getting this wrong: CI keeps running the previous image while the registry shows the new digest.
## Publishing workflow ## Publishing workflow
Publishing is CI-only by policy. Local `npm publish` is not supported. The maintainer triggers releases from `main`: Publishing is CI-only by policy. Local `npm publish` is not supported. The maintainer triggers releases from `main`:
+7 -2
View File
@@ -45,7 +45,12 @@ Maintenance:
☐ Add a minimal dir-listing webserver to the gitea docker setup for serving landing page (reuse existing reverse proxy) ☐ Add a minimal dir-listing webserver to the gitea docker setup for serving landing page (reuse existing reverse proxy)
☐ CI writes landing page to a shared volume keyed by project + tag (e.g. `/landing/tiny-pattern-ts/<tag>/`) ☐ CI writes landing page to a shared volume keyed by project + tag (e.g. `/landing/tiny-pattern-ts/<tag>/`)
☐ Browse to `…/tiny-pattern-ts/index.html` in the browser ☐ Browse to `…/tiny-pattern-ts/index.html` in the browser
☐ Stop Gitea CI re-downloading Node on every job (branch chore/fix-ci) ✔ Stop Gitea CI re-downloading Node on every job @done
✔ Share the warm npm cache with the publish job @done ✔ Share the warm npm cache with the publish job @done
✔ Bake Node into the CI job image (docker/Dockerfile, container.image in ci.yml) @done ✔ Bake Node into the CI job image (docker/Dockerfile, container.image in ci.yml) @done
☐ Build/push gitea.e1nsnull.de/tmu/act-ci:26.8.2 and confirm setup-node skips the download (first run on the branch = acceptance test) @high ✔ Build/push gitea.e1nsnull.de/tmu/act-ci:26.8.2 and confirm setup-node skips the download @done
✔ Write the `<version>/x64.complete` marker — actions/tool-cache ignores a bare directory, so the probe missed and the download continued @done
✔ Log tool-cache state from the job container to find it (temporary, removed once understood) @done
✔ Guard the invariant in CI (`Assert the baked tool cache is present`) @done
☐ Enable force-pull for the runner so a changed act-ci image is never missed @low
→ the tag encodes only the Node version, so a Dockerfile change yields new content under an unchanged tag; with `forcePull=false` the runner keeps the old image (see CONTRIBUTING § CI runner image)
+7
View File
@@ -39,6 +39,13 @@ ARG NODE_VERSION=26.8.2
# node image: bin/ + lib/ under /usr/local → tool cache: bin/ + lib/ under <ver>/x64. # node image: bin/ + lib/ under /usr/local → tool cache: bin/ + lib/ under <ver>/x64.
COPY --from=nodebase /usr/local /opt/hostedtoolcache/node/${NODE_VERSION}/x64 COPY --from=nodebase /usr/local /opt/hostedtoolcache/node/${NODE_VERSION}/x64
# actions/tool-cache only accepts a cached tool when the sibling marker file
# "<version>/<arch>.complete" exists — tc.find() checks it and falls back to
# downloading otherwise, however complete the directory is. The marker is what
# tc.cacheDir() writes after *it* installs a tool, so a pre-baked entry has to
# reproduce it explicitly.
RUN touch "/opt/hostedtoolcache/node/${NODE_VERSION}/x64.complete"
# Fail the build (not CI) if the overlay or the version arg were wrong. # Fail the build (not CI) if the overlay or the version arg were wrong.
# Shell form on purpose: exec form (`RUN [...]`) does not expand ARG values. # Shell form on purpose: exec form (`RUN [...]`) does not expand ARG values.
RUN "/opt/hostedtoolcache/node/${NODE_VERSION}/x64/bin/node" --version RUN "/opt/hostedtoolcache/node/${NODE_VERSION}/x64/bin/node" --version