Failing CI on Windows

[DanielRuf]

It seems some of the tests fail on Windows:
https://ci.appveyor.com/project/Daniel15/jest/builds/21990233

[thymikee]

We run our tests on Azure now

[DanielRuf]

Sure but this is still shown in the CI status (last commit) and the Azure Windows build was canceled.

[DanielRuf]

See https://github.com/facebook/jest/commits/master and the red CI status for all commits.

[SimenB]

There's some sort of issue with detectOpenHandles hanging. I haven't dug into it, but I'm suspecting some edge case due to an upgrade of node somewhere

[thymikee]

Yea, we need to figure out the failures of these 2 tests (interesting that they're different on AppVeyor vs Azure). Would you be able to help diagnose this?

[SimenB]

CI just passed: https://dev.azure.com/jestjs/jest/_build/results?buildId=452

There's been a couple of node releases, I wonder if one of them fixed whatever the issue was?

[SimenB]

Hmm, no. 10.15.1 has been used for both the hanging and the passing builds.

@kaylangan any idea about what might have changed? The previous 2 builds passed after the windows build always hung for some time: https://dev.azure.com/jestjs/jest/_build?definitionId=1&_a=summary

[kaylangan]

@SimenB I've been looking into this and haven't figured it out yet. I can't repro the failures locally and see that there are occasional passes. While we investigate, I suggest we set the timeout for the job to 35 minutes (maybe 30 if we wanted to be more aggressive) so that we don't unnecessarily tie up one of your 10 pipelines and results get sent back faster. I can submit a PR if that sounds ok with you.

[willsmythe]

I think this is caused by the upgrade of Yarn (1.9.4 to 1.13.0) on the hosted Windows image. If you look at the build history, the last successful build used 1.9.4, and every build after (which fails due to a timeout) has been on 1.13.0.

Without going into all the details right now (it's late), the until method in e2e/runJest.js which uses execa to spawn Jest, was previously spawning "node.exe" directly, but now spawns a shell (cmd.exe) that wraps node.cmd (yah, node.cmd). This changes the behavior when kill() is called on the jestPromise (the cmd.exe shell gets killed, but the node.cmd/node process hangs around).

Prior to Yarn 1.13.0, execa/cross-spawn would read the #! at the top of jest.js (the file being spawning) and use "which" to discover the .exe for node and then spawn it (see cross-spawn/../parse.js#L41). Yarn 1.13.0 injects what appears to be a temporary path at the start of $PATH that contains a "node.cmd". When cross-spawn calls "which", it now find this node.cmd, which cannot be spawned directly (it must must be wrapped in cmd.exe).

One option is to downgrade Yarn to 1.9.4 on Windows:

  - job: Windows
    pool:
      vmImage: vs2017-win2016
    steps:
      - script: |
          git config --global core.autocrlf false
          git config --global core.symlinks true
        displayName: 'Preserve LF endings and symbolic links on check out'

==>   - script: npm install -g yarn@1.9.4   
          
      - template: .azure-pipelines-steps.yml

This successfully builds the latest commit from master, see: https://dev.azure.com/willsmythe/jest/_build/results?buildId=486

It would be good to explore why Yarn is creating its own node.cmd and putting it at the front of $PATH.

[DanielRuf]

Was yarn installed with or without node? Did not check it yet.

[DanielRuf]

Related: yarnpkg/yarn#3255

[SimenB]

Oh wow, that must have been hard to track down. Thanks!

@Daniel15 @arcanis something you've encountered?