mirror of
https://github.com/openclaw/openclaw.git
synced 2026-07-22 21:41:16 +00:00
f69cb2f75e
* perf(ci): serve node_modules snapshots from O(1) protected sticky disks Every Blacksmith mount of the dependency sticky disk currently 429s: the v2 key minted one backing disk per PR and per manifest hash, which saturated Blacksmith's installation-wide 1000-sticky-disk budget (run 29559333389, job checks-node-compact-small-15: "Sticky disk limit exceeded"). Same-repo shards then fall back to a cold, storeless pnpm install (~40s) on every run - worse than the ~22s actions/cache path the sticky rollout replaced. Re-key the snapshot to one stable disk per node-version and move the install inputs into a runtime fingerprint marker: - Key is now `<repo>-node-deps-bind-v3-<node-version>`; dependency changes refresh the disk in place instead of allocating a new one. - The fingerprint (manifest hashFiles set + node version + lockfile mode) is evaluated on the bind step, before the mount lands, so the '**/package.json' glob cannot sweep snapshot-internal manifests. - Consumers mount read-only (commit: false); on fingerprint match they restore importer archives and skip pnpm install entirely, on mismatch they install against the clone's on-disk store (warm store, no actions/cache download) without capturing. - Writers are trusted non-PR jobs only: build-artifacts on canonical pushes plus the scheduled vitest-cache-warm run as a deadline writer (main pushes cancel each other under merge traffic and would starve the snapshot). commit: on-change keeps warm no-op runs from committing. - Roll the consumer flag out to every Linux Blacksmith lane that installs dependencies (build-artifacts, check-shard, check-additional-shard, check-docs, checks-ui, control-ui-i18n, native-i18n, qa-smoke-ci-profile, checks-fast-core, both contract shards) with the same fork/dispatch gates as the nondist shard. Guards now enumerate the consumer set, pin the O(1) key shape, enforce single-writer commit expressions, and cover the fingerprint marker in the importer capture/restore helper. Verified locally: importer archive capture 0.96s/228K and restore 0.07s against the real 2.0GB hoisted tree; a snapshot untarred into a fresh workspace resolves modules, runs bin shims, `pnpm exec`, and a Vitest suite (one-time pnpm reconcile only when the absolute path changes, which Blacksmith's fixed /home/runner/_work layout avoids). * fix(ci): commit dependency snapshots explicitly, not via on-change heuristic stickydisk's on-change mode compares allocated disk bytes with a 4KB threshold, so a fingerprint refresh whose reinstall keeps usage stable (metadata-only manifest edits, same-sized dependency swaps) could be silently discarded, stranding every consumer on a stale marker and a permanent reinstall path. Writers now commit explicitly, mirroring the Vitest transform disk's rationale; warm no-op writer runs re-commit an identical snapshot, which is cheap and safe. Also document that the non-PR commit gate binds cooperating code only - the enforced trust boundary stays the fork/dispatch runner gate, matching the protected node-compile disk's posture. * test(ci): guard sticky consumers against writerless node-version key splits Reviewer follow-up: the snapshot key is partitioned by node-version and both writers (build-artifacts, vitest-cache-warm) rely on the action default, so a consumer pinning any other version would split onto a key nobody seeds and silently regress to permanently cold installs. Pin the action default to 24.x and assert every sticky consumer resolves to that same key segment. * test: narrow sticky-consumer step.with before indexing The filter's runtime narrowing did not carry into the map callback, so step.with indexing failed check-test-types (TS18048). Collect a narrowed stepWith instead.