Jenkins Error "Error: spawn cmd ENOENT"

[akeresztesgh]

Hi, I'm running Cypress on Jenkins in Windows and am experiencing strange behavior. When I first setup Cypress to run in a build, it ran fine, but every time after that, it fails with Error: spawn cmd NOENT

Also, I changed the user that Jenkins runs as and Cypress ran only the first time the build ran, but after the first run, I get the same errors.

Current behavior:

Opening Cypress...

{ Error: spawn cmd ENOENT
    at exports._errnoException (util.js:1024:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:192:19)
    at onErrorNT (internal/child_process.js:374:16)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)

  code: 'ENOENT',
  errno: 'ENOENT',
  syscall: 'spawn cmd',
  path: 'cmd',
  spawnargs: 
   [ '/c',
     'WMIC path win32_process get Name,Processid,ParentProcessId,Commandline' ] }
Error: spawn cmd ENOENT
    at exports._errnoException (util.js:1024:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:192:19)
    at onErrorNT (internal/child_process.js:374:16)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)

�[?25hBuild step 'Execute Windows batch command' marked build as failure
Finished: FAILURE

Desired behavior:

I would like Cypress to run my tests inside of headless mode.

Steps to reproduce: (app code and test code)

I don't have a public repo to recreate this. If need, I could let somebody take a look at my build server. I'm just executing ./node_modules/.bin/cypress run from a windows batch command inside of Jenkins.

Versions

Windows Server 2016
Cypress 3.2.0
Jenkins latest

[flotwig]

Looks like this error code is coming from the find-process module which we make use of in packages/server:

https://github.com/yibn2008/find-process/blob/62c9211c691e8ee46169b6df5e15a33c47f3aa23/lib/find_process.js#L120

cypress/packages/server/lib/util/find_process.js

Line 4 in ef3c337

return findProcess('pid', pid)

In your Jenkins job, do you just have ./node_modules/.bin/cypress run inside of a .bat file that you then execute from the Jenkinsfile? Are you setting any node-related or shell-related environment vars or anything like that?

[akeresztesgh]

Hi and thanks for the reply.
I'm just running the command from a "batch command" inside of Jenkins. I do know that Jenkins does set env vars but I'm not using them.

I could try running it inside of a power shell command instead

[flotwig]

Can you share your Jenkinsfile here?

[akeresztesgh]

I'm using a freestyle project (not pipeline).

[akeresztesgh]

In the pic, I tried switching it to powershell (instead of windows batch command) and got the same result

[flotwig]

Is your cypress:headless command ./node_modules/.bin/cypress run? Try changing it in your package.json to just be cypress run - npm automatically looks for the binary in ./node_modules/.bin

[akeresztesgh]

here's the script:
"cypress:headless": "./node_modules/.bin/cypress run"
I changed it to:
"cypress:headless": "cypress run"

It gets me to the same spot (error)

[akeresztesgh]

I find it odd that Cypress runs correctly the first time, but after that it continues to fail. (If I change the user that the jenkins service uses to run as to something new, it will run once, and then continue to fail.)

[akeresztesgh]

@flotwig could you explain how you tracked down the location of this issue? I'm not a node guru and this could definitely be beneficial in the future.

[flotwig]

@akeresztesgh Yes, definitely a weird issue, not sure why exactly it's happening though

Sure, I can explain:

1. I searched for the string WMIC path win32_process get Name,Processid,ParentProcessId,Commandline from the error in our codebase using VS Code
2. That didn't return any results, so I used ag, the silver searcher to power-grep through all of our node_modules for WMIC like so:

   ➜  cypress git:(develop) ✗ ag "WMIC" -uaf .
   packages/server/node_modules/find-process/lib/find_process.js
   86:      const cmd = 'WMIC path win32_process get Name,Processid,ParentProcessId,Commandline'
   

3. That led me to the find-process module, then I did some Googling about "ENOENT on spawn" to give me some more context.

[akeresztesgh]

@flotwig thanks!

[akeresztesgh]

@flotwig as a test, I moved cmd.exe out of c:\windows\system32 and placed it into a temp folder, and added that to the path and it worked.

It's odd because I'm certain that system32 is in the path.

[jennifer-shehane]

Closing as resolved. Please comment if you are still having this issue and we will consider reopening.

[J-RZ]

@akeresztesgh were you able to solve this issue in another way? I just had the exact same thing and solved exactly as you described by moving cmd to another folder. I am running the latest 3.3.1

[akeresztesgh]

@akeresztesgh were you able to solve this issue in another way? I just had the exact same thing and solved exactly as you described by moving cmd to another folder. I am running the latest 3.3.1

@JorgeRamosZavala I haven't found a different solution yet.

[flotwig]

@akeresztesgh @JorgeRamosZavala Do you guys have C:\Windows\system32 in your PATH variable? That might be why this problem is happening. Check out this stackoverflow thread, people say that adding it to the PATH fixes this: https://stackoverflow.com/questions/28624686/get-spawn-cmd-enoent-when-try-to-build-cordova-application-event-js85

[jennifer-shehane]

Any updates here?

[bilegansorin]

Not sure if it's relevant but I'm having the same error when trying to integrate Cypress with Percy on macos:

[percy] percy has started.
events.js:177
      throw er; // Unhandled 'error' event
      ^

Error: spawn cypress ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:264:19)
    at onErrorNT (internal/child_process.js:456:16)
    at processTicksAndRejections (internal/process/task_queues.js:84:9)
Emitted 'error' event at:
    at Process.ChildProcess._handle.onexit (internal/child_process.js:270:12)
    at onErrorNT (internal/child_process.js:456:16)
    at processTicksAndRejections (internal/process/task_queues.js:84:9) {
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn cypress',
  path: 'cypress',
  spawnargs: [
    'run',
    '--browser',
    'chrome',
    '--spec',
    'cypress/integration/Regression/partner_test_flow.js'
  ]
}

[J-RZ]

Any updates here?

Any updates here?

Yeah it got fixed for me adding the string to the PATH variable. I had it like this: C:\\WINDOWS\\SYSTEM32 but that did not seem to work though, so I changed to C:/Windows/System32 and works just fine.

[bi379]

C:\Users\carnelian\CypressDash>npx cypress run --record --key [removed]

{ Error: spawn cmd ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:246:19)
    at onErrorNT (internal/child_process.js:429:16)
    at processTicksAndRejections (internal/process/task_queues.js:81:17)

  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn cmd',
  path: 'cmd',
  spawnargs:
   [ '/c',
     'WMIC path win32_process get Name,Processid,ParentProcessId,Commandline,ExecutablePath' ] }
Error: spawn cmd ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:246:19)
    at onErrorNT (internal/child_process.js:429:16)
    at processTicksAndRejections (internal/process/task_queues.js:81:17)

[flotwig]

Since nobody has reported having this issue after adding C:\Windows\system32 to their PATH, I'm going to close it and leave this workaround for any future readers:

Workaround

Do you have C:\Windows\system32 in your PATH variable? That might be why this problem is happening. Check out this stackoverflow thread, people say that adding it to the PATH fixes this: stackoverflow.com/questions/28624686/get-spawn-cmd-enoent-when-try-to-build-cordova-application-event-js85

If anyone has this issue and C:\windows\system32 IS in your PATH, please open a new issue linking to this one and we can see what's going on.

[php7134]

Still facing the same issue.

[jennifer-shehane]

@php7134 If you're experiencing a bug similar to this in Cypress, please open a new issue with a fully reproducible example that we can run. There may be a specific edge case with the issue that we need more detail to fix.