runner: hashFiles() couldn't finish within 120 seconds.

(filing here since I understand that hashFile() is owned by https://github.com/actions/runner)

Hey!

We have migrated a semi-large Unity project from SVN to Git / Github and I am working on setting up Actions for a build pipeline. Unfortunately, a step to create a cache for Unity-specific files is giving me a headache. If I understand the error message correctly, I am running into a 120 second timeout for that step.

As I see it, the timeout for hasFiles() is set here and there is no way to increase it, is that correct? https://github.com/actions/runner/blob/100c99f2635be35c7ea690c58fa7d203725cac9e/src/Runner.Worker/Expressions/HashFilesFunction.cs#L16

Expected behavior I imagine it makes a lot of sense that the job has a timeout. It would be helpful if it could be set from the step configuration for scenarios where a lot of files have to be hashed.

Runner Version and Platform

Runner version: 2.290.1 OS: Windows 10 64bit self hosted runner

Action configuration:

- uses: actions/cache@v3
  with:
    path: Library
    key: Library-${{ hashFiles('Assets\**', 'Packages\**', 'ProjectSettings\**') }}
    restore-keys: |
      Library-

Job Log Output

##[debug]Evaluating condition for step: 'Run actions/cache@v3'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Run actions/cache@v3
##[debug]Register post job cleanup for action: actions/cache@v3
##[debug]Loading inputs
##[debug]Evaluating: format('Library-{0}', hashFiles('Assets\**', 'Packages\**', 'ProjectSettings\**'))
##[debug]Evaluating format:
##[debug]..Evaluating String:
##[debug]..=> 'Library-{0}'
##[debug]..Evaluating hashFiles:
##[debug]....Evaluating String:
##[debug]....=> 'Assets\**'
##[debug]....Evaluating String:
##[debug]....=> 'Packages\**'
##[debug]....Evaluating String:
##[debug]....=> 'ProjectSettings\**'
##[debug]Search root directory: 'D:\actions-runner\_work\[omitted]\[omitted]'
##[debug]Search pattern: 'Assets\**, Packages\**, ProjectSettings\**'
##[debug]Starting process:
##[debug]  File name: 'D:\actions-runner\externals\node16\bin\node.exe'
##[debug]  Arguments: '"D:\actions-runner\bin\hashFiles"'
##[debug]  Working directory: 'D:\actions-runner\_work\[omitted]\[omitted]'
##[debug]  Require exit code zero: 'False'
##[debug]  Encoding web name:  ; code page: ''
##[debug]  Force kill process on cancellation: 'False'
##[debug]  Redirected STDIN: 'False'
##[debug]  Persist current code page: 'False'
##[debug]  Keep redirected STDIN open: 'False'
##[debug]  High priority process: 'False'
##[debug]Process started with process id 10936, waiting for process exit.
##[debug]Match Pattern: Assets\**
##[debug]Packages\**
##[debug]ProjectSettings\**
##[debug]::debug::followSymbolicLinks 'false'
##[debug]::debug::followSymbolicLinks 'false'
##[debug]::debug::implicitDescendants 'true'
##[debug]::debug::omitBrokenSymbolicLinks 'true'
##[debug]::debug::Search path 'D:\actions-runner\_work\[omitted]\[omitted]\Assets'
##[debug]::debug::Search path 'D:\actions-runner\_work\[omitted]\[omitted]\Packages'
##[debug]::debug::Search path 'D:\actions-runner\_work\[omitted]\[omitted]\ProjectSettings'

[looong list of files that are processed, omitted]

##[debug]Sending CTRL_C to process 10936.
##[debug]Successfully send CTRL_C to process 10936.
##[debug]Waiting for process exit or 7.5 seconds after CTRL_C signal fired.
##[debug]Ignore Ctrl+C to current process.
##[debug]STDOUT/STDERR stream read finished.
##[debug]STDOUT/STDERR stream read finished.
##[debug]Process exit successfully.
##[debug]Process cancelled successfully through Ctrl+C/SIGINT.
##[debug]Process Cancellation finished.
##[debug]Finished process 10936 with exit code -1073741510, and elapsed time 00:02:00.0198012.
Error: .github/workflows/main.yml (Line: 43, Col: 16):
Error: The template is not valid. .github/workflows/main.yml (Line: 43, Col: 16): hashFiles('Assets\**, Packages\**, ProjectSettings\**') couldn't finish within 120 seconds.
##[debug]GitHub.DistributedTask.ObjectTemplating.TemplateValidationException: The template is not valid. .github/workflows/main.yml (Line: 43, Col: 16): hashFiles('Assets\**, Packages\**, ProjectSettings\**') couldn't finish within 120 seconds.
##[debug]   at GitHub.DistributedTask.ObjectTemplating.TemplateValidationErrors.Check()
##[debug]   at GitHub.DistributedTask.Pipelines.ObjectTemplating.PipelineTemplateEvaluator.EvaluateStepInputs(TemplateToken token, DictionaryContextData contextData, IList`1 expressionFunctions)
##[debug]   at GitHub.Runner.Worker.ActionRunner.RunAsync()
##[debug]   at GitHub.Runner.Worker.StepsRunner.RunStepAsync(IStep step, CancellationToken jobCancellationToken)
##[debug]Finishing: Run actions/cache@v3

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 13
  • Comments: 19 (1 by maintainers)

Commits related to this issue

Most upvoted comments

@JJ: Assuming that the runtime is performing hashFiles() at step evaluation, you should be able to perform your own hashing on disk in a step…

Old:

      - name: Cache Maven dependencies
        uses: actions/cache@v2
        with:
          path: ~/.m2/repository
          key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
          restore-keys: |
            ${{ runner.os }}-maven-

Replacement:

      - name: Workaround hashFiles timeout
        run: |
          find ~/.m2/repository -name pom.xml -print0 | xargs -0 shasum > ~/.m2/repository/pom.xml.shasum
      - name: Cache Maven dependencies
        uses: actions/cache@v2
        with:
          path: ~/.m2/repository
          key: ${{ runner.os }}-maven-${{ hashFiles('pom.xml.shasum') }}
          restore-keys: |
            ${{ runner.os }}-maven-
    ...
      - name: Workaround hashFiles timeout update
        run: |
          find ~/.m2/repository -name pom.xml -print0 | xargs -0 shasum > ~/.m2/repository/pom.xml.shasum

Disclaimers:

  1. This isn’t tested
  2. find, xargs, shasum might not be available for your OS/Shell, as applicable you may need to replace the commands…
  3. Please don’t randomly trust random people’s code w/o inspecting / considering it 😄

@shtefanilie my issue with this also started with Podfile.lock issues then I realized that GHA was using the cached version of my Podfile. I had to force the cache to get busted by changing the hash name like “-pods-v2” so GHA would see the cache doesn’t exist and then recreate the Podfile.lock file. Just leaving it here as it could help others too 😊

@JJ What I personally did, was to remove entirely the actions/cache steps from my flow. Otherwise, my release would’ve still been blocked. What was very weird was that it started with Podfile.lock issues, and after removing that one, the yarn.lock caching failed soon after. So in the end I had to remove all of them. Sadly it seems nobody is interested in that PR @Carsten-MaD opened…

I have the same problem when using the cache action to cache Maven artifacts. I have 320 pom.xml files “only”, in my repository. I wonder why it take more than 2 minutes to calculate the hash of these small files.

I call the action that way:

      - name: Cache Maven dependencies
        uses: actions/cache@v2
        with:
          path: ~/.m2/repository
          key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
          restore-keys: |
            ${{ runner.os }}-maven-

And I’m running on a self-hosted Windows Server 2016.

Bump. Came across this issue repeatedly. Please merge and release the fix soon!

@MikulasMascautanu I want to say that my issue and what you describe are not necessarily of the same nature. In my case, it makes a lot of sense that hashing all the files would indeed take longer than two minutes: It is a rather large Unity game project. My issue is that I would like it to enable to take longer, also see the PR mentioned above.

Your case seems to be a bit different: Often it finishes in under two minutes, sometimes it does not. In such a case, there might be a different underlying reason, potentially with the mechanic that hashes the files itself.