hashFiles function throwing error.
See original GitHub issueWe 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

Issue Analytics
- State:
- Created 2 years ago
- Comments:21 (5 by maintainers)
 Top Results From Across the Web
Top Results From Across the Web
hashFiles function returns nothing instead of hash of the file ...
(Doc) No error is thrown during the execution of the action, but no hash is generated either. This leads to invalid behavior when...
Read more >NodeJS Hash files using klaw recursive function in a directory
I'm trying to hash every single file in a directory and then print the output into a .txt file on nodeJS. But the...
Read more >RSFirewall! Changelog - RSJoomla!
Fixed - Backend Captcha was throwing an error due to changes in Joomla! 4.1.4. ... 3.7.0; Updated - Code improvements and deprecated functions...
Read more >7 Github Actions Tricks I Wish I Knew Before I Started
The catch? ... continue-on-error: true ... different files and call them from other workflows – just like you would a function or a...
Read more >How to: CI/CD/IaC for Azure Function Apps and GitHub Actions
I'll show you how I implement CI & CD in my Azure Functions Apps to ... if (isNaN(operandA) || isNaN(operandB)) { throw new...
Read more > Top Related Medium Post
Top Related Medium Post
No results found
 Top Related StackOverflow Question
Top Related StackOverflow Question
No results found
 Troubleshoot Live Code
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free Top Related Reddit Thread
Top Related Reddit Thread
No results found
 Top Related Hackernoon Post
Top Related Hackernoon Post
No results found
 Top Related Tweet
Top Related Tweet
No results found
 Top Related Dev.to Post
Top Related Dev.to Post
No results found
 Top Related Hashnode Post
Top Related Hashnode Post
No results found

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
hashFilescould 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
hashFilesreturns an empty string?I resolved this by changing this:
to this: