sadpandajoe opened a new pull request, #45909: URL: https://github.com/apache/superset/pull/45909
### SUMMARY The pre-commit workflow's Setup Node.js step used setup-node's built-in `cache: npm`, which keys on the exact `superset-frontend/package-lock.json` hash with no fallback. Every push or PR that changes the lockfile (every Dependabot npm bump, for example) therefore starts `npm ci` with an empty cache and downloads ~2,850 tarballs, including `xlsx` from `cdn.sheetjs.com` rather than the npm registry. That makes the job fail whenever the registry or that CDN has a blip during the install. Between 2026-10-22 and 10-29 two `pre-commit (current)` runs failed this way and passed on re-run with no code change ([40649064300](https://github.com/apache/superset/actions/runs/40649064300): `ECONNRESET` after an 11-minute stall; [40679638770](https://github.com/apache/superset/actions/runs/40679638770): `503` on `cdn.sheetjs.com/xlsx-0.20.3/xlsx-0.20.3.tgz`), and a master `pre-commit (next)` run timed out stalled in the same step ([40678215774](https://github.com/apache/superset/actions/runs/40 678215774)). No specific introducing change: this is how setup-node's cache has always keyed. This replaces it with an `actions/cache` step on `~/.npm` keyed `npm-v1-<os>-<lockfile hash>` with a `npm-v1-<os>-` restore prefix, gated on the same `needs_node` condition as Setup Node.js. After a lockfile change, `npm ci` starts from the most recent cache and fetches only the changed packages. This reduces the exposure; it does not remove it (the first run after merge, or after the cache is evicted, still installs cold). Not a retry, timeout or skip. Measured locally (npm 11, `npm ci --ignore-scripts`, one-package lockfile change): 2 network GETs with a cache from the previous lockfile (the changed tarball plus a revalidation of the `dom-to-image` git dependency) vs 1,270 with an empty cache; `xlsx` served from cache. CI runs on this PR: in progress, numbers to follow. ### TESTING INSTRUCTIONS 1. On this PR, open the `pre-commit (current)` job: the new **Cache npm** step logs `Cache not found` for `npm-v1-Linux-...` on the first run and saves the cache at the end; a re-run logs `Cache restored from key: npm-v1-Linux-<hash>`. 2. After merge, on the next PR that changes `superset-frontend/package-lock.json`, the Cache npm step logs `Cache restored from key: npm-v1-Linux-<a different hash>` (prefix fallback), and Install Frontend Dependencies finishes without re-downloading the unchanged packages. 3. The cache only grows across lockfile changes; changing `npm-v1` to `npm-v2` resets it. ### ADDITIONAL INFORMATION - [ ] Has associated issue: - [ ] Required feature flags: - [ ] Changes UI - [ ] Includes DB Migration (follow approval process in SIP-59) - [ ] Migration is atomic, supports rollback & is backwards-compatible - [ ] Confirm DB migration upgrade and downgrade tested - [ ] Runtime estimates and downtime expectations provided - [ ] Introduces new feature or API - [ ] Removes existing feature or API 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
