Strange sporadic "Could not get yarn cache folder path" with v3 #887
Assignees
Labels
bug
Something isn't working
Comments
|
Thank you for the detailed issue description! We will investigate the problem and come back to you with the details. |
|
For posterity, have been experiencing the sporadic issue as well. Started noticing it after an upgrade to node 20. I then updated the setup-node action to v4 as I saw the runtime of that action was node-20. The upgrade to v4 reduced the amount of times we see the error but it still happens, just less than on v3. |
|
yarn cache apparently not working for the same Ubuntu / hosted setup with node 20 and actions v4 Configuration: - uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'yarn'Log: actions/setup-node@v4
node: v20.10.0
npm: 10.2.3
yarn: 4.0.2
/usr/local/bin/yarn --version
4.0.2
/usr/local/bin/yarn config get cacheFolder
/home/runner/.yarn/berry/cache
/usr/local/bin/yarn config get enableGlobalCache
true
yarn cache is not found |
|
I can notice the same sporadic problem since a recent update to Node 20 + actions/setup-node@v4. @xcq1 Do you have found any way to bypass the problem since the creation of the report? |
|
We're running into this issue consistently since a few days ago. Here is the Runner info: Our config: with:
node-version-file: frontend/educator/.nvmrc
cache: yarn
cache-dependency-path: frontend/educator/**/yarn.lock
always-auth: false
check-latest: false
token: ***And the full logs of the error
|
|
@frederic-saunier Unfortunately not. As far as I know upgrading to v4 did reduce the frequency, but the problem is definitely still there. |
|
Hello! I'm facing a similar issue, however not with |
|
I think I am running into this as well, but it doesn't seem to be intermittent though |
|
I'm still running into this issue, I've tried the above steps but no dice. |
|
We're seeing these sporadic failures too |
|
I'm guessing there are probably multiple causes of this issue, but I managed to fix it on my own repositories by specifying the In other words, I changed to I see someone above already specified yarn.lock so this probably isn't the only reason for failure, but it worked for me. |
|
Hello @xcq1, Thank you for bringing this issue to our attention. We have thoroughly investigated the situation and were unable to reproduce the problem you're experiencing with the actions/setup-node workflow.
If you could provide more details with public repro link about your setup or any specific error messages you're receiving, it would be helpful for further investigation. |
|
Hello @xcq1, Please provide more details with public repro link about your setup or any specific error messages you're receiving, it would be helpful for further investigation as we are unable to reproduce the issue from our end. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description:
We currently encounter sporadic issues in our CI pipelines that make use of setup-node@v3 with Yarn 1 Caching. During
setup-nodethe commandyarn cache dirfails for only one (apparently) random project folder with exit code 1, at least the error messageCould not get yarn cache folder path for ...is printed, and the build fails. This started around the time we migrated the CI to Node 20 in mid-October.These issues are not easily reproducible since it works fine most of the time, but then fails in only one very specific place only. The GHA workflow contains multiple very similar jobs that perform the same setup, and of these only one job fails the command in only one particular folder. After one to a few rebuilds the issue has usually resolved itself. Unfortunately, with enough repositories, CI jobs and project folders, it's only a question of time until it pops up again.
Sometimes, the error message is accompanied by what appears to be a V8/nodejs Stacktrace crashing somewhere about
v8::internal::Deserializercalled bynode::contextify::ContextifyScript::New(v8::FunctionCallbackInfo<v8::Value> const&) [node]with eitheror
Clearing the caches from Management > Caches in the Actions UI did not help, and after looking through all the code that gets executed until this point and could (or could not) cause such issues, and being unable to find anyone else with the same issue, I'm having a really hard time understanding how this can happen.
In one build I noticed something else rather odd: the debug output of
/usr/local/bin/yarn --versionwas inconsistent and printed1.18.0instead of1.22.19. In all other builds however, they all report the same version (1.22.19).So my best guess is we're experiencing some sort of very specific setup race condition or so, although I can't say what is causing this. I'm open for any suggestions how to further debug/resolve this.
Action version:
v3, last occurred with
'actions/setup-node@v3' (SHA:1a4442cacd436585916779262731d5b162bc6ec7)Platform:
Runner type:
Tools version:
ubuntu-latest Runners (Ubuntu 22.04.3)
node: v20.9.0
npm: 10.1.0
yarn: 1.22.19
Repro steps:
Unfortunately the repos where this happens are private, but I have caught one instance with
ACTIONS_RUNNER_DEBUG: trueandACTIONS_STEP_DEBUG: trueset in this workflow:ci-build.yaml
Now here are the logs of test-webfrontend/1_Set up job:
Set up job
And then it fails in test-webfrontend/3_Run actionssetup-node@v3:
Run actionssetup-node@v3 with error
Compare this to the start of build-webfrontend/3_Run actionssetup-node@v3 where the very same command works just fine:
Run actionssetup-node@v3 without error
Expected behavior:
Action completes setting up the cache and not failing the build.
Actual behavior:
Action nondeterministically fails the build due to the issue described.
The text was updated successfully, but these errors were encountered: