Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CI] Run tests on Windows #20260

Closed
hramos opened this issue Jul 17, 2018 · 33 comments
Closed

[CI] Run tests on Windows #20260

hramos opened this issue Jul 17, 2018 · 33 comments
Labels
Platform: Windows Building on Windows. Resolution: Locked This issue was locked by the bot. 🔩Test Infrastructure Test infrastructure and continuous integration. Type: Discussion Long running discussion.

Comments

@hramos
Copy link
Contributor

hramos commented Jul 17, 2018

For Discussion

Our suite of tests does not currently run on Windows machines. This results in a blind spot that has allowed issues affecting Windows users to creep into the code base (facebook/metro#181).

Circle CI does not support running jobs on Windows at the moment. I'd like to open a discussion and get feedback from the community on how to proceed.

@hramos hramos added Platform: Windows Building on Windows. 🔩Test Infrastructure Test infrastructure and continuous integration. Core Team Type: Discussion Long running discussion. labels Jul 17, 2018
@kelset
Copy link
Collaborator

kelset commented Jul 18, 2018

A while back @matthargett suggested that to fix the CircleCI "Windows absence" we could integrate AppVeyor CI

@gengjiawen
Copy link
Contributor

Recently babel add Appveyor too.

@charpeni
Copy link
Contributor

I agree that AppVeyor CI would be a good alternative and it looks like from their homepage that Facebook is already one of their great customers.

As starting point, maybe we can introduce some basic Windows tests like:

  1. Clone the repository and use the cli (from local repository) to init a fresh React Native project.
  2. From this fresh project, bundle the JavaScript (local-cli/cli.js bundle).

With this we should be able to catch issues like #20015.

@gengjiawen
Copy link
Contributor

I have created a pr #20281, hope it helps.

@kelset
Copy link
Collaborator

kelset commented Jul 18, 2018

Yeah I think that's a "good enough" start, and then we can ask Windows dev to jump in and add more tests as the platform becomes more widely used.

@gengjiawen
Copy link
Contributor

Okay, the basic setup is okay, and we can wait for facebook/metro#181 to be fixed.
Current build log: https://ci.appveyor.com/project/gengjiawen/react-native/build/job/x476xw6q46hg5h3e.

@gengjiawen
Copy link
Contributor

So what test should on windows platform run ? Aside from basic android build. I also add some npm run test, but some test case are failed.

Personally I want to add metro debug server bundle works as expected.

@gengjiawen
Copy link
Contributor

@hramos Can you check the appveyor config or the badge url. Looks like README.md now has not show any build in appveyor.

@gengjiawen
Copy link
Contributor

The windows issue (#20353) still exists on master branch now. So we do need a test case to test the request to http://localhost:8081/RNTester/js/RNTesterApp.android.delta?platform=android&dev=true&minify=false works on windows.

I will see what I can do after my two prs got merged.

@gengjiawen
Copy link
Contributor

gengjiawen commented Sep 2, 2018

Currently the android build works on appveyor, but we have some jest test failure.

Test Suites: 16 failed, 2 skipped, 90 passed, 106 of 108 total
Tests:       54 failed, 4 skipped, 545 passed, 603 total
Snapshots:   42 passed, 42 total
Time:        12.803s

Most of those related to On a win32 FS, the options' cwd() must return a valid win32 absolute path.

Error: On a win32 FS, the options' `cwd()` must return a valid win32 absolute path. This happened while trying to resolve: `c:\empty`

      33 |       continue;
      34 |     }
    > 35 |     fs.mkdirSync(entPath);
         |        ^
      36 |     mockDir(entPath, ent);
      37 |   }
      38 | }

      at MemoryFs._resolve (node_modules/metro-memory-fs/src/index.js:830:15)
      at MemoryFs.mkdirSync (node_modules/metro-memory-fs/src/index.js:994:5448)
      at mockDir (local-cli/__mocks__/fs.js:35:8)
      at MemoryFs.setMockFilesystem [as __setMockFilesystem] (local-cli/__mocks__/fs.js:17:3)
      at Object.<anonymous> (local-cli/core/__tests__/android/getDependencyConfig.spec.js:23:19)

cc @rafeca

@hramos
Copy link
Contributor Author

hramos commented Sep 4, 2018

Just an FYI: I just enabled facebook/react-native on Appveyor. Builds should be running now.

@jeanlauliac
Copy link

I have a fix for the fs-related failure, it's due to a problem in the way the test are setup and not specific to metro-memory-fs. Will send soon.

@gengjiawen
Copy link
Contributor

@jeanlauliac Hopefully we can fix the windows ci via your pr :)

facebook-github-bot pushed a commit that referenced this issue Sep 17, 2018
Summary:
@public

These tests are using a mock memory FS to start with, so there is no reason at all they should depend on the host OS or filesystem details. This changeset fixes that so that we fully mock the `fs` and `path` modules dependending on the mock platform (not the host platform). I also added an example of how we can test both platforms (regardless of the host platform) in `findPackageClassName`. Follow up changeset will be to do the same for all the other affected tests.

Related to #20260.

Reviewed By: mjesun

Differential Revision: D9771024

fbshipit-source-id: b368b43e8e54292d33b6183eec9a9ea69f2e6e76
@jeanlauliac
Copy link

jeanlauliac commented Sep 17, 2018

Please try past e327f88, hopefully that adresses issues with the fs mock that were happening on Windows.

@gengjiawen
Copy link
Contributor

gengjiawen commented Sep 19, 2018

@jeanlauliac Good job. Test case fail number on windows from 54 to 7.

@gengjiawen
Copy link
Contributor

I have create a pr to fix remaining failed case: #21203.
With the pr, we only have one failed case:

 FAIL  local-cli/link/__tests__/ios/writePlist.spec.js
  ● Test suite failed to run

    TypeError: require(...).join is not a function

      24 | const writePlist = require('../../ios/writePlist');
      25 | 
    > 26 | const projectPath = path.join(__dirname, '../../__fixtures__/project.pbxproj');
         |                                   ^
      27 | const infoPlistPath = path.join(__dirname, '../../__fixtures__/Info.plist');
      28 | 
      29 | fs.readFileSync = jest.fn(() => readFileSync(projectPath).toString());

cc @jeanlauliac Can you help on this ?

@jeanlauliac
Copy link

Yeah that's because path doesn't get mocked early enough. Changeset on the way.

@jeanlauliac
Copy link

jeanlauliac commented Sep 24, 2018

9c242c8 should fix the issue. Let me know.

@gengjiawen
Copy link
Contributor

gengjiawen commented Sep 26, 2018

@jeanlauliac It looks like cause more problem, now it have three fails, plz check https://ci.appveyor.com/project/facebook/react-native/branch/master/job/9s95x3eb1f937qrk.

grabbou pushed a commit to react-native-community/cli that referenced this issue Sep 26, 2018
Summary:
@public

These tests are using a mock memory FS to start with, so there is no reason at all they should depend on the host OS or filesystem details. This changeset fixes that so that we fully mock the `fs` and `path` modules dependending on the mock platform (not the host platform). I also added an example of how we can test both platforms (regardless of the host platform) in `findPackageClassName`. Follow up changeset will be to do the same for all the other affected tests.

Related to facebook/react-native#20260.

Reviewed By: mjesun

Differential Revision: D9771024

fbshipit-source-id: b368b43e8e54292d33b6183eec9a9ea69f2e6e76
@jeanlauliac
Copy link

jeanlauliac commented Sep 27, 2018

The errors on the report are not related to the JS tests are they? It looks like build errors.

@gengjiawen
Copy link
Contributor

Nope, it's test case.

@jeanlauliac
Copy link

We're not looking at the same thing then. In the link you sent, here's the only error I can see:

FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring root project 'react-native'.
> Could not resolve all files for configuration ':classpath'.
   > Could not resolve com.sun.xml.fastinfoset:FastInfoset:1.2.13.
     Required by:
         project : > com.android.tools.build:gradle:3.1.4 > com.android.tools.build:gradle-core:3.1.4 > com.android.tools.build:builder:3.1.4 > com.android.tools:sdklib:26.1.4 > com.android.tools:repository:26.1.4 > org.glassfish.jaxb:jaxb-runtime:2.2.11
      > Could not resolve com.sun.xml.fastinfoset:FastInfoset:1.2.13.
         > Could not get resource 'https://jcenter.bintray.com/com/sun/xml/fastinfoset/FastInfoset/1.2.13/FastInfoset-1.2.13.pom'.
            > Could not GET 'https://jcenter.bintray.com/com/sun/xml/fastinfoset/FastInfoset/1.2.13/FastInfoset-1.2.13.pom'. Received status code 504 from server: Gateway Time-out
   > Could not resolve javax.xml.bind:jaxb-api:2.2.12-b140109.1041.
     Required by:
         project : > com.android.tools.build:gradle:3.1.4 > com.android.tools.build:gradle-core:3.1.4 > com.android.tools.build:builder:3.1.4 > com.android.tools:sdklib:26.1.4 > com.android.tools:repository:26.1.4 > org.glassfish.jaxb:jaxb-runtime:2.2.11 > org.glassfish.jaxb:jaxb-core:2.2.11
      > Skipped due to earlier error
   > Could not resolve org.glassfish.jaxb:txw2:2.2.11.
     Required by:
         project : > com.android.tools.build:gradle:3.1.4 > com.android.tools.build:gradle-core:3.1.4 > com.android.tools.build:builder:3.1.4 > com.android.tools:sdklib:26.1.4 > com.android.tools:repository:26.1.4 > org.glassfish.jaxb:jaxb-runtime:2.2.11 > org.glassfish.jaxb:jaxb-core:2.2.11
      > Skipped due to earlier error
   > Could not resolve com.sun.istack:istack-commons-runtime:2.21.
     Required by:
         project : > com.android.tools.build:gradle:3.1.4 > com.android.tools.build:gradle-core:3.1.4 > com.android.tools.build:builder:3.1.4 > com.android.tools:sdklib:26.1.4 > com.android.tools:repository:26.1.4 > org.glassfish.jaxb:jaxb-runtime:2.2.11 > org.glassfish.jaxb:jaxb-core:2.2.11
      > Skipped due to earlier error
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1m 34s
Command exited with code 1

What am I missing? 🙂

@gengjiawen
Copy link
Contributor

gengjiawen commented Sep 27, 2018

@hramos
Copy link
Contributor Author

hramos commented Sep 27, 2018

Here's the error report from the above link:

Summary of all failing tests
FAIL Libraries/Interaction/__tests__/InteractionManager-test.js
  ● promise tasks › should also work with a deadline
    expect(received).toBe(expected) // Object.is equality
    Expected: 1
    Received: 0
      14 | 
      15 | function expectToBeCalledOnce(fn) {
    > 16 |   expect(fn.mock.calls.length).toBe(1);
         |                                ^
      17 | }
      18 | 
      19 | describe('InteractionManager', () => {
      at expectToBeCalledOnce (Libraries/Interaction/__tests__/InteractionManager-test.js:16:32)
      at Timeout._onTimeout (Libraries/Interaction/__tests__/InteractionManager-test.js:294:7)
FAIL local-cli/link/__tests__/ios/writePlist.spec.js
  ● ios::writePlist › should write a `.plist` file
    ENOENT: no such file or directory, open 'C:\projects\__fixtures__\project.pbxproj'
      27 | const infoPlistPath = path.join(__dirname, '../../__fixtures__/Info.plist');
      28 | 
    > 29 | fs.readFileSync = jest.fn(() => readFileSync(projectPath).toString());
         |                                                          ^
      30 | 
      31 | const {writeFileSync} = fs;
      32 | fs.writeFileSync = jest.fn(writeFileSync);
      at Object.<anonymous> (local-cli/link/__tests__/ios/writePlist.spec.js:29:58)
      at pbxProject.Object.<anonymous>.pbxProject.parseSync (node_modules/xcode/lib/pbxProject.js:44:28)
      at Object.<anonymous> (local-cli/link/__tests__/ios/writePlist.spec.js:43:13)
  ● ios::writePlist › should write a `.plist` file
    ENOENT: `/Basic/Info.plist`: no such file or directory
      27 |   // indentation of the plist.
      28 |   // Ref: https://github.com/facebook/react-native/issues/11668
    > 29 |   return fs.writeFileSync(
         |                        ^
      30 |     plistPath,
      31 |     plistParser.build(plist, {indent: '\t', offset: -1}) + '\n',
      32 |   );
      at makeError (node_modules/metro-memory-fs/src/index.js:1239:15)
      at MemoryFs._resolveEnt (node_modules/metro-memory-fs/src/index.js:877:13)
      at MemoryFs._resolve (node_modules/metro-memory-fs/src/index.js:850:12)
      at MemoryFs._open (node_modules/metro-memory-fs/src/index.js:736:10)
      at Object.writeFileSync (node_modules/metro-memory-fs/src/index.js:994:5210)
      at writePlist (local-cli/link/ios/writePlist.js:29:24)
      at Object.<anonymous> (local-cli/link/__tests__/ios/writePlist.spec.js:49:49)
  ● ios::writePlist › when plistPath is null it should return null
    ENOENT: no such file or directory, open 'C:\projects\__fixtures__\project.pbxproj'
      27 | const infoPlistPath = path.join(__dirname, '../../__fixtures__/Info.plist');
      28 | 
    > 29 | fs.readFileSync = jest.fn(() => readFileSync(projectPath).toString());
         |                                                          ^
      30 | 
      31 | const {writeFileSync} = fs;
      32 | fs.writeFileSync = jest.fn(writeFileSync);
      at Object.<anonymous> (local-cli/link/__tests__/ios/writePlist.spec.js:29:58)
      at pbxProject.Object.<anonymous>.pbxProject.parseSync (node_modules/xcode/lib/pbxProject.js:44:28)
      at Object.<anonymous> (local-cli/link/__tests__/ios/writePlist.spec.js:43:13)
  ● ios::writePlist › when plistPath is null it should return null
    expect(jest.fn()).not.toHaveBeenCalled()
    Expected mock function not to be called but it was called with:
      ["/Basic/Info.plist", "<?xml version=\"1.0\" encoding=\"UTF-8\"?>
    <!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">
    <plist version=\"1.0\">
    <dict>
    	<key>CFBundleDevelopmentRegion</key>
    	<string>en</string>
    	<key>UISupportedInterfaceOrientations</key>
    	<array>
    		<string>UIInterfaceOrientationPortrait</string>
    	</array>
    </dict>
    </plist>
    "]
      55 |     plistPath = null;
      56 |     expect(writePlist(project, '/', plist)).toBeNull();
    > 57 |     expect(fs.writeFileSync).not.toHaveBeenCalled();
         |                                             ^
      58 |   });
      59 | });
      60 | 
      at Object.<anonymous> (local-cli/link/__tests__/ios/writePlist.spec.js:57:45)
Test Suites: 2 failed, 2 skipped, 104 passed, 106 of 108 total
Tests:       3 failed, 4 skipped, 601 passed, 608 total
Snapshots:   42 passed, 42 total
Time:        31.172s
Ran all test suites.
npm ERR! Test failed.  See above for more details.

A few of these appear to be issues reading from the filesystem on Windows. For example:

ENOENT: no such file or directory, open 'C:\projects\__fixtures__\project.pbxproj'

@gengjiawen
Copy link
Contributor

@jeanlauliac ping

@jeanlauliac
Copy link

The changeset partly fixes things only, I think :) for the rest I'd have to grab a windows VM and try out.

As for the InteractionManager-test.js this may be flakiness and I do not believe this is related to the fs mock. I have no context on that test I'm afraid.

@gengjiawen
Copy link
Contributor

@jeanlauliac Glad to hear, I hope we can fix this soon. Maybe @rafeca can help you with the windows part, he fix some metro issue on windows machine.

@empyrical
Copy link
Contributor

Since this issue was created, Microsoft released this:

https://azure.microsoft.com/en-ca/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/

Which may be an option if appveyor is being too troublesome. That InteractionManager issue is really odd, because I cannot reproduce it on my windows VM at all.

@gengjiawen
Copy link
Contributor

gengjiawen commented Oct 17, 2018

@empyrical Windows 10 ? I have the issue on my win10 too.

@hramos
Copy link
Contributor Author

hramos commented Oct 17, 2018

Appveyor is still red -- what do you folks think about removing Appveyor.yml from the master branch until this is fixed? It makes it hard to see when Circle CI tests have broken when looking at the list of recent commits. I hope Appveyor does let you run tests on a branch that includes Appveyor.yml, similar to how Circle CI works, as that would help verify the status of those tests.

@empyrical
Copy link
Contributor

I've used AppVeyor without issue on my React Native fork, not sure about other branches on the same repo though.

But if someone wants to try and fix this last remaining test on their fork it would work fine.

@gengjiawen
Copy link
Contributor

@empyrical Can you share your success link in your react native fork ?

@empyrical
Copy link
Contributor

Oh, sorry, I didn't get the test working on my fork.

What I mean is, if someone wants to make an attempt at fixing the failing InteractionManager test, AppVeyor will work fine for testing on their personal React Native fork

t-nanava pushed a commit to microsoft/react-native-macos that referenced this issue Jun 17, 2019
Summary:
@public

These tests are using a mock memory FS to start with, so there is no reason at all they should depend on the host OS or filesystem details. This changeset fixes that so that we fully mock the `fs` and `path` modules dependending on the mock platform (not the host platform). I also added an example of how we can test both platforms (regardless of the host platform) in `findPackageClassName`. Follow up changeset will be to do the same for all the other affected tests.

Related to facebook#20260.

Reviewed By: mjesun

Differential Revision: D9771024

fbshipit-source-id: b368b43e8e54292d33b6183eec9a9ea69f2e6e76
t-nanava pushed a commit to microsoft/react-native-macos that referenced this issue Jun 17, 2019
Summary:
@public

Partly fixes facebook#20260

Reviewed By: rafeca

Differential Revision: D10302150

fbshipit-source-id: 2d9a63b263c9e27c22989c447ce884934f1e4430
@facebook facebook locked as resolved and limited conversation to collaborators Nov 6, 2019
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Nov 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Platform: Windows Building on Windows. Resolution: Locked This issue was locked by the bot. 🔩Test Infrastructure Test infrastructure and continuous integration. Type: Discussion Long running discussion.
Projects
None yet
Development

No branches or pull requests

7 participants