Diagnostics for `hashFiles` failing on a broken symlink don't describe the problem
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 6.3k
- Forks
- 1.4k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 24
Description
Describe the bug
Currently if hashFiles hits a broken symlink it fails the step hard with an opaque error: it says that there is a problem, but no guidance about what it was. For instance:
Error: The template is not valid. .github/workflows/test.yml (Line: 14, Col: 14): hashFiles('*') failed. Fail to hash files under directory '/home/runner/work/GitHub-runner-broken-symlink-diagnostics/GitHub-runner-broken-symlink-diagnostics'
That is all it says, without debug logging. This is confusing and frustrating, and is even worse with a glob like some-directory/**/*: who knows which file somewhere under that directory is the problem.
Given the job is failing, preferably this would do at least one of:
- include which file(s) is causing the problem
- suggest how to find more information, e.g. "turn on debug logging".
Debug logging helps with this, somewhat, if one knows what to look for (I had to find https://github.com/actions/runner/issues/1666 to realise I could search for ENOENT in the logs, since there was too much output to look at manually):
##[debug]Error: ENOENT: no such file or directory, stat '/home/runner/work/GitHub-runner-broken-symlink-diagnostics/GitHub-runner-broken-symlink-diagnostics/broken'
##[debug] at Object.statSync (node:fs:1583:3)
##[debug] at /home/runner/runners/2.311.0/bin/hashFiles/index.js:84:24
##[debug] at Generator.next (<anonymous>)
##[debug] at fulfilled (/home/runner/runners/2.311.0/bin/hashFiles/index.js:35:58) {
##[debug] errno: -2,
##[debug] syscall: 'stat',
##[debug] code: 'ENOENT',
##[debug] path: '/home/runner/work/GitHub-runner-broken-symlink-diagnostics/GitHub-runner-broken-symlink-diagnostics/broken'
##[debug]}
To Reproduce
- Have a broken symlink somehow
- Have a
hashFilescall in the workflow that includes that symlink - See error and then struggle to understand what needs to be changed to fix the problem
Example: https://github.com/huonw/GitHub-runner-broken-symlink-diagnostics
- run without debug logging: https://github.com/huonw/GitHub-runner-broken-symlink-diagnostics/actions/runs/7028745161/job/19125215085
- run with debug logging: https://github.com/huonw/GitHub-runner-broken-symlink-diagnostics/actions/runs/7028745161/job/19125266914
Expected behavior
It would be better if the error message said:
- which files are a problem (preferably if there's multiple files that are a problem, highlight them all)
- why they're a problem (e.g. "symlink to file that doesn't exist")
1 is most critical, but 2 would be great.
Runner Version and Platform
Current runner version: '2.311.0'
Operating System
Ubuntu
22.04.3
LTS
What's not working?
The error is opaque, currently:
Error: The template is not valid. .github/workflows/test.yml (Line: 14, Col: 14): hashFiles('*') failed. Fail to hash files under directory '/home/runner/work/GitHub-runner-broken-symlink-diagnostics/GitHub-runner-broken-symlink-diagnostics'
Job Log Output
- run without debug logging: https://github.com/huonw/GitHub-runner-broken-symlink-diagnostics/actions/runs/7028745161/job/19125215085
- run with debug logging: https://github.com/huonw/GitHub-runner-broken-symlink-diagnostics/actions/runs/7028745161/job/19125266914
Runner and Worker's Diagnostic Logs
N/A
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the broken-symlink workflow described in the issue, comparing the normal and debug logs. Trace the hashFiles entry point and its error-reporting path; done means the failure identifies the problematic file(s) and, where feasible, explains the cause or directs users to useful diagnostics.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- ci-cd, devops
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100