Commit 7769f2f
fix(pnpm-install): pin lock-hash to a step output so cache-save survives teardown
`actions/cache@v4` re-evaluates `key:` in its post-step (cache-save) at job
teardown. On some self-hosted / k8s runners the workspace is wiped before
the post-step runs, so `hashFiles('**/pnpm-lock.yaml')` returns no files
and fails the entire job — even when every real step has already passed.
Capture the hash once in a regular `run:` step (where `hashFiles` is
evaluated against the live workspace) and feed the resulting value into
the cache `key:` via `steps.pnpm-lock-hash.outputs.HASH`. Step outputs
are stored in the runner's `_temp/` state and survive workspace teardown,
so the post-step evaluation of `key:` no longer touches the filesystem.
Functionally equivalent on healthy runners — same hash, same cache key.
Observed in the wild against `apify-core`: cypress shard 6 of run
https://github.com/apify/apify-core/actions/runs/25511344092, where all
41 specs passed but the job was failed by `Post Install dependencies`
with `hashFiles('**/pnpm-lock.yaml') failed. Fail to hash files under
directory '/home/runner/_work/apify-core/apify-core'`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>1 parent 46dde02 commit 7769f2f
1 file changed
Lines changed: 13 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
67 | 67 | | |
68 | 68 | | |
69 | 69 | | |
| 70 | + | |
| 71 | + | |
| 72 | + | |
| 73 | + | |
| 74 | + | |
| 75 | + | |
| 76 | + | |
| 77 | + | |
| 78 | + | |
| 79 | + | |
| 80 | + | |
| 81 | + | |
70 | 82 | | |
71 | 83 | | |
72 | 84 | | |
73 | 85 | | |
74 | | - | |
| 86 | + | |
75 | 87 | | |
76 | 88 | | |
77 | 89 | | |
| |||
0 commit comments