Runner: workflow fails on Run actions/setup-node@v1

Created on 14 Sep 2020  路  12Comments  路  Source: actions/runner

Associated GitHub Community ticket: https://github.community/t/ci-started-to-fail-on-run-actions-setup-node-v1/131883

The customer is using CI workflow to generate NPM package. Recently, the workflow started to fail when running actions/setup-node@v1 .
The customer said that they did not changed any configurations of workflow.
The following is the error message:

Run actions/setup-node@v1
  with:
    node-version: 12
    registry-url: https://npm.pkg.github.com/
    scope: @ierp-ai
    always-auth: false
##[error]No such file or directory
##[debug]System.ComponentModel.Win32Exception (2): No such file or directory
##[debug]   at System.Diagnostics.Process.ForkAndExecProcess(String filename, String[] argv, String[] envp, String cwd, Boolean redirectStdin, Boolean redirectStdout, Boolean redirectStderr, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
##[debug]   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
##[debug]   at System.Diagnostics.Process.Start()
##[debug]   at GitHub.Runner.Sdk.ProcessInvoker.ExecuteAsync(String workingDirectory, String fileName, String arguments, IDictionary`2 environment, Boolean requireExitCodeZero, Encoding outputEncoding, Boolean killProcessOnCancel, Channel`1 redirectStandardIn, Boolean inheritConsoleHandler, Boolean keepStandardInOpen, Boolean highPriorityProcess, CancellationToken cancellationToken)
##[debug]   at GitHub.Runner.Common.ProcessInvokerWrapper.ExecuteAsync(String workingDirectory, String fileName, String arguments, IDictionary`2 environment, Boolean requireExitCodeZero, Encoding outputEncoding, Boolean killProcessOnCancel, Channel`1 redirectStandardIn, Boolean inheritConsoleHandler, Boolean keepStandardInOpen, Boolean highPriorityProcess, CancellationToken cancellationToken)
##[debug]   at GitHub.Runner.Worker.Handlers.DefaultStepHost.ExecuteAsync(String workingDirectory, String fileName, String arguments, IDictionary`2 environment, Boolean requireExitCodeZero, Encoding outputEncoding, Boolean killProcessOnCancel, Boolean inheritConsoleHandler, CancellationToken cancellationToken)
##[debug]   at GitHub.Runner.Worker.Handlers.NodeScriptActionHandler.RunAsync(ActionRunStage stage)
##[debug]   at GitHub.Runner.Worker.ActionRunner.RunAsync()
##[debug]   at GitHub.Runner.Worker.StepsRunner.RunStepAsync(IStep step, CancellationToken jobCancellationToken)
##[debug]Finishing: Run actions/setup-node@v1

I also tested the setup-node v1 action with the similar inputs on my side, but did not reproduce the issue. The action can work fine without any errors.

Most helpful comment

I resolved my failing CI with 2 changes:

  1. As @khhhum suggested, changed checkout to version 2 from version 1. -> Why there is such dependency, no idea and if you have breaking change, it must be somehow communicated
  1. There is another breaking change, originally when setting working-directory in run command, CI would change the directory and stay there for all consequent actions, now the working directory is always root so I need to rewrite the workflow -> again why there is such a breaking change without communication ...

馃

All 12 comments

Adding some details to this

  • We started hitting this issue some time at night thursday september 10th
  • We are using self-hosted runners, on ubuntu 18.04
  • We see the problem for multiple marketplace as well as custom actions, e.g. also "setup-java"
  • Forcing the runnings back onto the previous version 2.273.0 seems to make it work again, but since they are auto-upgraded it is not a useful workaround
  • It seems like there is a race condition involved as it will work sometimes, but not very often. Stomach feeling is it fails >90% of the time
  • it becomes a bigger problem because you cannot re-run a single job, only all of them

Let me know what other details you need

Transferred this to the https://github.com/actions/runner repo since it seems related to the release.

@BrightRan in your tests: https://github.com/TestWorkflowsRML/GHA-Syntax/actions/runs/253535466/workflow you are using the newer v2.x versions of the github checkout action. But the original poster, as well as us are using "v1"

upgrading to v2 of the github checkout action seems to have solved the issue for us. Would like to understand why :)

I resolved my failing CI with 2 changes:

  1. As @khhhum suggested, changed checkout to version 2 from version 1. -> Why there is such dependency, no idea and if you have breaking change, it must be somehow communicated
  1. There is another breaking change, originally when setting working-directory in run command, CI would change the directory and stay there for all consequent actions, now the working directory is always root so I need to rewrite the workflow -> again why there is such a breaking change without communication ...

馃

Glad to have found this issue as we were seeing the same problem. I can also confirm that updating to checkout v2 AND changing the working dir inside each step fixes the problem.

Now the drag of updating the workflows in 100+ repos. I'd also love to know why the breaking change in checkout v1.

Sorry to hear you are encountering issues. We are working on a fix for this bug and will update this issue with more information as soon as it is available!

Sorry to hear all of you are encountering this!

I have good news, we are working on rolling out a new runner version to fix this issue, and should be rolled out to all customers as soon as we can safely do so in the next day or two!

In the meantime, you should be able to upgrade to actions/checkout@v2 to fix this issue.
Something to note, actions/checkout@v2 no longer sets the github workspace to the path input, which means you may need to manually set the working directory for your runs step

We strongly recommend using actions/checkout@v2 and you should upgrade as soon as it is feasible for you to do so.

We have also identified the missing test that would have covered this use case, and will address that gap.

Thank you @thboop for the update and your effort 馃憤

Thanks @thboop for the update and the fix! I did indeed sweep all of our repos this morning and switched to checkout v2 and added a cd to each of the steps where we needed to set the folder (I'm going to go back and use working-directory instead now!).

I guess the plus is I've got most of our repos using checkout v2 (and took the time to update to cache v2 at the same time!)

Thanks again!

in our case, bugs in the v2 checkout actions prevents us from upgrading. But I can confirm that the new release of the github runner fixes the problem with v1 for us.

The new Runner is rolled out! I'm going to close this issue but please let me know if you are still seeing problems and we can reopen this issue and address them!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

asomers picture asomers  路  5Comments

SeyfSV picture SeyfSV  路  7Comments

jl-gogovapps picture jl-gogovapps  路  4Comments

ScottOFX picture ScottOFX  路  3Comments

Maxim-Mazurok picture Maxim-Mazurok  路  5Comments