Binary caching does not respect cache setting

[lizzielizzielizzie]

Hi,
I'm currently working on tuning our CI performance but I've run into an issue where sentry's install script is always downloading the binary to ~/.npm/ rather than the directory configured in my .npmrc or the directory specified when running npm ci --cache myProjectCacheFolder. Because it's not installing to the correct cache folder, our runners can't pick it up, which means it gets redownloaded for each job (🙁)

I don't have this issue with any other package, as~/.npm/ only has the sentry-cli folder (everything else is in my project's cache folder). I also added a little script to my package.json

  scripts: {
    "print-env-vars": "printenv | grep npm_config_cache"
  }

and running the command outputs

npm_config_cache=myProjectCacheFolder

Which means the setting is definitely correct at the "top leve", but perhaps not carried through into the install script's environment. If you have any ideas at all for how to resolve this, I'd be really appreciative, as I've been scratching my head on this one all day

[kamilogorek]

What CI are you using? Different services handle caches differently. I just verified it locally, and both scenarios (config option and --cache) work just fine - fetch first, use cached on 2nd run.

[lizzielizzielizzie]

We're using gitlab, but I'm able to reproduce the issue just on my mac with npm v6.10.3 and node v12.10.0

At the end of this screenshot you can see that even though the npm cache has been placed inside the project directory (consistent with the env setting), sentry-cli's cache for the binary has been placed at ~/.npm/sentry-cli

If we run npm ci again, it uses the cache and never fetches the binary. This is good, ‼but‼ if we delete ~/.npm, which is not where the cache has been configured, it has to fetch the binary again to install, again indicating the binary is saved where it shouldn't be.

I would assume this behavior is because of this line in the setup script, but I don't understand why process.env.npm_config_cache is unset at that point.

[lizzielizzielizzie]

Turns out it was an issue with npm ci dropping certain config settings from the environment. Upgrading npm to the latest version solved the issue :) You can read more here

[kamilogorek]

Good to know, thanks!