Every job starts on a clean machine, so npm 2,036 ci downloads BookNest's 82 packages each time unless npm's download cache (~/.npm) survives between runs. actions/setup-node keeps it with one input:
steps:
- uses: actions/checkout@v7
- uses: actions/setup-node@v7
with:
node-version: ${{ matrix.node }}
cache: npm
- run: npm cisetup-node restores ~/.npm before npm ci and, if nothing matched, saves it afterward. It caches downloads, not node_modules, so npm ci still installs exactly what the lock file says. The first run on main:
gh run view 36132132510 --log | grep -E 'Cache saved|Cache hit for:|cache is not found' \
| awk -F'\t' '{sub(/^[^ ]* /, "", $3); print $1 ": " substr($3, 1, 44)}'Output
test (ubuntu-24.04, node 24): Cache hit for: node-cache-Linux-x64-npm-874b test (ubuntu-24.04, node 22): npm cache is not found test (ubuntu-24.04, node 22): Cache saved with the key: node-cache-Linux-x test (ubuntu-24.04-arm, node 24): npm cache is not found test (ubuntu-24.04-arm, node 24): Cache saved with the key: node-cache-Linux-a test (ubuntu-24.04, node 26): Cache hit for: node-cache-Linux-x64-npm-874b package: Cache hit for: node-cache-Linux-x64-npm-874b
The first x64 job to finish saved the cache and later ones hit it; arm64 keeps its own. Yet pull request #17's run had saved identical keys minutes earlier: caches belong to the branch that made them (Cache Keys).