hashFiles function throwing error.

[moerishabh]

We are facing issue with node caching today on ubuntu-18.04. Following is the error

 hashFiles('../../**/package-lock.json') failed. Fail to hash files under directory

This has been working for the past 2 years. However starting today morning we are facing this issue

   uses: actions/cache@v1
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-cache-${{ hashFiles('../../**/package-lock.json')}}
          restore-keys: |
            ${{ runner.os }}-node-cache-

24 hours back it was running as expected

[vsvipul]

@moerishabh Any reason why you are still using the old v1 version of API instead of v2? Regarding your problem- Can you try giving an absolute path for package-lock.json and avoid using ** as it may cause problems for subnested package-lock.json files inside node_modules ? or is it what you want ?

[moerishabh]

@vsvipul I checked with v2 as well, getting the same error. This is a monorepo so there are multiple packages-lock.json files https://github.com/actions/cache/blob/main/examples.md#node---lerna.

[dhadka]

@moerishabh Any chance the ../../ was recently added to the hashFiles path in your workflow? I ran a test just now and see the following error:

##[debug](node:1540) UnhandledPromiseRejectionWarning: AssertionError [ERR_ASSERTION]: Invalid pattern '../../**/package-lock.json'. Relative pathing '.' and '..' is not allowed.
##[debug]    at Function.fixupPattern (/home/runner/runners/2.287.1/bin/hashFiles/index.js:2331:9)
##[debug]    at new Pattern (/home/runner/runners/2.287.1/bin/hashFiles/index.js:22[46](https://github.com/dhadka/cache-test-2/runs/5407959738?check_suite_focus=true#step:4:46):27)
##[debug]    at Function.<anonymous> (/home/runner/runners/2.287.1/bin/hashFiles/index.js:1179:42)
##[debug]    at Generator.next (<anonymous>)
##[debug]    at /home/runner/runners/2.287.1/bin/hashFiles/index.js:1026:71
##[debug]    at new Promise (<anonymous>)
##[debug]    at module.exports.297.__awaiter (/home/runner/runners/2.287.1/bin/hashFiles/index.js:1022:12)
##[debug]    at Function.create (/home/runner/runners/2.287.1/bin/hashFiles/index.js:1165:16)
##[debug]    at Object.<anonymous> (/home/runner/runners/2.287.1/bin/hashFiles/index.js:1007:56)
##[debug]    at Generator.next (<anonymous>)

I needed to enable step debug logging to see the full error message shown above.

[Dragory]

I started experiencing this on v2 today. The action has not been changed in over 6 months. Here's the configuration:

      - name: Cache Composer dependencies
        uses: actions/cache@v2
        with:
          path: /tmp/composer-cache
          key: ${{ runner.os }}-${{ hashFiles('**/composer.lock') }}

The step initially works, but then throws an error in the Post task:

[dhadka]

🤔 Interesting. Thanks for the extra confirmation @Dragory . I do see a new version of the runner was released ~yesterday~ a few days ago - https://github.com/actions/runner/releases/tag/v2.288.1. The one change I see that could affect this is:

Prefer node16 over node12 when running internal scripts

[dhadka]

What version does it show under the Set up job step? For example:

Current runner version: '2.287.1'

[dhadka]

After discussing this internally, we think this is related to - https://github.com/actions/runner/pull/1678. Essentially hashFiles was previously failing silently but with the new runner version it will raise an Error instead.

You can also see this was the case in @moerishabh 's screenshot, where it shows:

key: Linux-node-cache-
restore-keys: Linux-node-cache-

Essentially, the hash was never getting computed + added to the key.

@moerishabh I think you can fix that by removing the relative paths of ../../. @Dragory I'm not exactly sure why yours is failing. Could you please enable step debug logging, re-run the workflow, and look at the extra debug output to see what error it shows?

[dhadka]

Also pinning for visibility

[math0ne]

I resolved this by changing this:

      - uses: actions/cache@v2
        with:
          path: '**/node_modules'
          key: ${{ runner.os }}-modules-${{ hashFiles('**/yarn.lock') }}

to this:

      - uses: actions/cache@v2
        with:
          path: '/node_modules'
          key: ${{ runner.os }}-modules-${{ hashFiles('/yarn.lock') }}

[benzhu56]

Ours problem is **/composer.lock instead. I'm wondering if changing to composer.lock would cause any problem, since it will then only hash the composer.lock file in root folder, and not including those under vendors folder. I reckon it's okay because if any of the composer.lock files are changed under vendors, then the main composer.lock under root folder should have changed first (lib versions, etc), right?

[moerishabh]

thanks @dhadka we were able to resolve this issue by changing ../../package-lock.json to **/package-lock.json.

[mbg]

We also started running into this issue today. After enabling step debug logging, it seems that for us the error was caused by a permissions issue. Specifically, during the CI run, a folder was created by Docker within the workspace with permissions that meant that hashFiles could not search that folder for files which matched our search pattern. I assume that this failed silently before, but is now an error due to https://github.com/actions/runner/pull/1678.

We are able to resolve this either by making the pattern more concrete (e.g. instead of using **/*.cabal, we could use **/foo.cabal, but then we need to be careful about adding all package files explicitly now and in the future) or by moving the folder created by Docker outside the workspace.

In any case, I am wondering though if the solution implemented by https://github.com/actions/runner/pull/1678 could be improved. At least, it would be nice to have a better indication of what the error is without having to enable step debug logging. Perhaps the errors should be warnings instead? Or perhaps there should only be an error if hashFiles returns an empty string?

[Sephster]

echoing what @mbg has said, I am also suffering from this issue due to a docker permissions issue. Using **/composer.json as the pattern, the run fails when trying to access the mysql volume created by docker.

[jbarop]

In our case it was caused because there was an access error during file matching.

##[debug][Error: EACCES: permission denied, scandir '/home/runner/work/xxx'] { 
##[debug] errno: -13, 
##[debug] code: 'EACCES', 
##[debug] syscall: 'scandir', 
##[debug] path: '/home/runner/work/xxx' 

[vbraun]

For me, specifying an absolute path in the key

      - uses: actions/cache@v2
        with:
          path: '/artifacts'
          key: cache-key-${{ hashFiles('/src/**') }}

just creates an empty key, i.e. cache-key- as if hashfiles returns the empty string. This is a self-hosted runner, in case it matters.

I see lots of projects linked on this issue that "fixed" this and now have keys that do not have any hash in them any more, this is going to be a cluster**** when they start changing their sources and keep downloading stale caches.

Really hashFiles should error out if there is a glob that does not match anything, or if there is a file that does not exist. Ideally with a sane error message that tells us what the whole glob was, including any prepended workspace paths. Hashfiles should never return the empty string.

[vbraun]

To debug the issue you can manually run hashFiles by logging in to the self-hosted worker and evaluating (in the work directory)

$ patterns='src/**' node  ~/bin.2.288.1/hashFiles/index.js

In my case, hashFiles fails because of a dangling symlink that throws an Error: ENOENT. If it succeeds you get the hash printed to stdout, e.g.:

$ patterns=.github/cache-version node  ~/bin.2.288.1/hashFiles/index.js 
Match Pattern: .github/cache-version
::debug::followSymbolicLinks 'false'
::debug::followSymbolicLinks 'false'
::debug::implicitDescendants 'true'
::debug::omitBrokenSymbolicLinks 'true'
::debug::Search path '/var/home/agent-91/_work/talque/talque/.github/cache-version'
/var/home/agent-91/_work/talque/talque/.github/cache-version
Found 1 files to hash.
__OUTPUT__ae876d3c7f80bd4544e167f2dabe3af79d5a3e052c5ff4226cd95c03895fc700__OUTPUT__
undefined

And it clearly is reevaluated in the Post Run actions/cache@v2 step, because that is where it errors out for me. That makes zero sense at all; the cache key must be the one from the Run actions/cache@v2 step. Later there will typically be build artifacts that will be picked up by globs.

[howyi]

It appears that the globstar(**) process is different from the shell and may fail with errors accessing subdirectories. I fixed it in this PR. :chicken: https://github.com/actions/toolkit/pull/1015

However Fail to hash files under directory is just one of the causes of the failure. Once approved, it can work by increasing the version of @actions/glob used by hashFiles

[Chrischuck]

@howyi So once your fix goes in, we don't have to change anything on our end, correct?

[howyi]

@Chrischuck Yes, if the cause is due to [Permission denied], you do not need to do anything. 👌🏿

If you want to see the cause of the hashFiles error, you need to enable debug logging. If you see [Permission denied] (example), my PR will automatically fix it.

However, since it has not been reviewed, it remains to be seen when a fix will be made... 😩

[danielsantos-25friday]

I'm facing the same issue, I've retried several times with "enable debug logging" and always get error Permission Denied ##[debug]::debug::Search path '/home/runner/work/gha-hashfiles-parmission-check/gha-hashfiles-parmission-check' ##[debug][Error: EACCES: permission denied, scandir ...

[maplessmann]

In my case I'm using cypress-io/github-action and was getting the EACCES: permission denied error. I fixed it by running containers as user 1001

container:
  image: cypress/browsers:node14.17.0-chrome88-ff89
  options: --user 1001

According to this old version of the cypress-io/github-action README:

This issue is caused by the user not having the right permissions to the cache directory, and seems to only happen when using a docker container.

In order to fix this, you need to specify a specific user to run the container.

user 1001 is a special user within GitHub Actions which has the necessary permissions to write to /github/home/....

[github-actions[bot]]

This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.

[github-actions[bot]]

This issue was closed because it has been inactive for 5 days since being marked as stale.

[sp0033212000]

I'm facing the same issue, I've retried several times with "enable debug logging" and always get error Permission Denied ##[debug]::debug::Search path '/home/runner/work/gha-hashfiles-parmission-check/gha-hashfiles-parmission-check' ##[debug][Error: EACCES: permission denied, scandir ...

do you find any solution yet? I am also facing this error now, but cannot find any way out...