ENOTEMPTY errors since setting cache: npm

[gr2m]

I have seen several instances of this error in the past few days across several @octokit repositories

npm ERR! code ENOTEMPTY
npm ERR! syscall rename
npm ERR! path /home/runner/work/types.ts/types.ts/node_modules/npm/node_modules/.libnpmdiff.DELETE/node_modules/.cache
npm ERR! dest /home/runner/work/types.ts/types.ts/node_modules/npm/node_modules/libnpmdiff/node_modules/.cache
npm ERR! errno -39
npm ERR! ENOTEMPTY: directory not empty, rename '/home/runner/work/types.ts/types.ts/node_modules/npm/node_modules/.libnpmdiff.DELETE/node_modules/.cache' -> '/home/runner/work/types.ts/types.ts/node_modules/npm/node_modules/libnpmdiff/node_modules/.cache'

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/runner/.npm/_logs/2021-07-21T16_51_25_184Z-debug.log

Example: https://github.com/octokit/types.ts/runs/3126289089?check_suite_focus=true#step:6:4

We recently enabled the cache: npm across all @octokit repositories, so it's pretty likely that the error is related. I'm cannot be 100% sure, but I thought it'd be worth creating the issue to see if others run into it, too.

Do you have any idea what it could be?

[viceice]

Seeing the same on yarn since v2.3.0, see containerbase/internal-tools#246

[dmitry-shibanov]

Hello @gr2m. Thank you for your report. It looks like you're getting the wrong cache. I'm not sure that it's related to actions/setup-node, because we cache global cache directory. We've tested your build with cache and without it and the build fails. Moreover, we've tested your previous commits before 072ae93bef5edc7a487a286e8c86aa3d02f59cbd and it works as expected. Could it be related to some other dependencies updated in this commit ?

Hello @viceice. You're getting the error because cached path does not exist. If you take a look on the previous green builds you'll notice that cache archive is empty. The related issue is #281. Your path's output contains color addition, that is why it can't find such directory.

[viceice]

@dmitry-shibanov Thank, that fixed it for us.

[gr2m]

Thanks for checking @dmitry-shibanov. Feel free to close the issue, I will comment or reopen if I find out more.

Maybe the problem was caused by caching that was done previously using the actions/cache that we used in several repositories.

[dmitry-shibanov]

Thank you for your responses. I'm closing the issue. Feel free to contact us, if you have any questions.

[maxim-lobanov]

@gr2m , it is not related to previous caching using actions/cache since it uses different cache keys.

The issue is related to npm install @octokit/openapi-types@latest command.
See how it works:

1. npm ci command restores dependencies based on package-lock.json
2. npm install @octokit/openapi-types@latest install the latest version of openapi-types library
3. Post-job step caches global cache (including specific version of openapi-types) using hash key of package-lock.json
4. Next build is looking at package-lock.json, see that it is not changed and restores the cache (all dependencies + specific version of openapi-types)
5. When openapi-types version is bumped, build tries to install @octokit/openapi-types@latest in runtime and fails for some reason because cache contains the previous version.

I guess removing this step is not the option for you so I think changing step order will solve your issue (I have removed other steps to simplify):

- run: npm install @octokit/openapi-types@latest
  if: github.event_name == 'repository_dispatch'
- uses: actions/setup-node@v2
  with:
    node-version: "12.x"
    cache: npm
- run: npm ci

Why this approach will work - the first command will modify package.json and package-lock.json and update this line to latest version (only during the build and for one build). Then updated package-lock.json will be used for caching in setup-node and everything will work correctly. Every time when version of library is updated, cache will be recalculated / rebuild because package-lock.json cache will be changed.

[gr2m]

I'll try that approach, thanks Maxim!