"Castor" caches the node_modules directory after each gate-and-submit pipeline job. And it loads it at the beginning of all pipeline's jobs.
However, the job always runs:
00:00:33.100 + rm -rf node_modules 00:00:33.101 + npm install
As such, the cache is ignored. The original reason for this probably doesn't apply anymore (it's mostly because the directory was retained between runs because the workspace wasn't cleaned up, afaik we do this everywhere now and/or run on Nodepool where each instances is destroyed afterward anyway).
However, even if we make sure that 4e9a7314d2b5c21899f2c329f7e5748c8b55abef is no longer a problem (node_modules preserved between npm-setup-oid jobs that point node_modules to a deploy.git-style repo), there may be other issues we need to think about. For example:
- We don't clear the cache periodically (it'd grow indefinitely as unused dependencies will linger).
- May cause unexpected side-effects in case of npm modules that use autodiscovery to change their behaviour - it would find a module that is no longer there on fresh install.
- May cause code to pass even if a package is wrongly removed from package.json.
- We don't clear the cache after upgrading npm in CI. In theory the cache consumer in npm is meant to be backward-compatible, but I don't know for how many releases back that support goes or how well tested this is by upstream.
Zuul will abort Jenkins jobs when their result is no longer relevant (e.g. patch-set is updated, or dependant commit failed). This may abort an npm-install process prematurely without it being able to leave behind a clean state.
- Shouldn't be an issue since we only run castor-save after a completed and successful build.
- Verify 4e9a7314d2b5c is no longer a problem.
- Draft a change that changes rm -rf node_modules; npm install to npm prune && npm install (should address point 1).