[STCLI-140] BigTest doesn't work on Windows machines Created: 03/Jul/19  Updated: 20/Sep/19  Resolved: 24/Jul/19

Status: Closed
Project: stripes-cli
Components: None
Affects versions: None
Fix versions: 1.13.0

Type: Bug Priority: P1
Reporter: Taras Tkachenko Assignee: Anton Emelianov (Inactive)
Resolution: Done Votes: 0
Labels: bigtest
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
defines FOLIO-2142 BigTest doesn't work on Linux machine... Closed
Sprint:

 Description   

BigTest doesn't work on Windows machines and actually does not even install on them.
This is a critical issue that causes massive Mac computers requests that are extemely time-consuming due to delivery time and workstation software and infrastructure setup.
The option to set up virtual environment with Linux is also flawed to its own BigTest issues and is also time consuming.

Preliminary cause of this behaviour is PhantomJS usage.
PhantomJS has never worked on Windows cause it uses non-handled UNIX symlinks which are not exist on any of Windows file systems.
At the top of this PhantomJS is deprecated for several years and nobody uses it if you'll look at the other testing frameworks.



 Comments   
Comment by Jeffrey Cherewaty [ 03/Jul/19 ]

Taras Tkachenko could you point me to the repository that you've tried to run on Windows?

Comment by Taras Tkachenko [ 04/Jul/19 ]

Hi Jeffrey Cherewaty
The repos are `ui-data-import` and `ui-inventory` (I haven't tried the others but I'm pretty sure it doesn't work either).

Comment by Jeffrey Cherewaty [ 05/Jul/19 ]

Taras Tkachenko I haven't spun up a Windows VM to reproduce yet, but BigTest doesn't rely on PhantomJS at all. BigTest is explicitly not meant to be used with headless browsers.

I ran yarn why phantomjs-prebuilt for ui-inventory, and it's being pulled in by favicons-webpack-plugin, which was removed from stripes-core with https://github.com/folio-org/stripes-core/pull/657. The inventory module might just be due for some dependency updates.

Comment by Zak Burke [ 09/Jul/19 ]

I cannot reproduce the phantomjs-prebuilt dependency chain in ui-inventory, ui-data-import, or platform-complete. As Jeffrey Cherewaty noted, favicons-webpack-plugin was removed from stripes-core for release v3.4.0, which has been part of stripes since v2.5.0 was released in May.

Jeffrey Cherewaty, Taras Tkachenko, are you certain you're seeing this dependency-chain with current builds of these repos?

Comment by John Coburn [ 09/Jul/19 ]

Previously, I've had to switch to using a pre-release of karma-webpack v4 where they fixed a windows pathing issue... at that time I set up a branch of stripes-cli called windows-testing that upgraded the dependency to the pre-release of v4. It looks like they've recently released v4 - we'll have to try it out and see if we can get it merged into master of stripes-cli.
Taras Tkachenko The windows-testing branch of stripes-cli probably needs to be updated to master, but you can try it out in your local workspace and see if things behave better.

Comment by Jeffrey Cherewaty [ 09/Jul/19 ]

Well I blew away my local yarn.lock for ui-inventory and phantom went away. Hadn't realized that yarn.lock isn't in source control. It probably should be.

John Coburn's probably on the right track with karma-webpack causing some problems: https://github.com/webpack-contrib/karma-webpack/issues/396

Comment by John Coburn [ 09/Jul/19 ]

windows-testing branch updated, PR submitted to stripes-cli to use the official release of karma-webpack v4.

Comment by Anton Emelianov (Inactive) [ 12/Jul/19 ]

Taras Tkachenko, could you please verify that these changes are resolving reported issue?

Comment by Taras Tkachenko [ 12/Jul/19 ]

Hi Anton Emelianov The latest @stripes-cli (v.1.13.1x) is not available for installation yet.
On 1.12.1 BigTest starts (at last!) but all the tests failed.

Comment by Zak Burke [ 15/Jul/19 ]

Well I blew away my local yarn.lock for ui-inventory and phantom went away. Hadn't realized that yarn.lock isn't in source control. It probably should be.

NB: We generally omit yarn.lock files from app repos because, ultimately, dependencies are resolved at the platform level, i.e. local lock files are ignored. Thus, in the context of a non-platform repository, they provide a false sense of security. They may be worthwhile from the point of view of unit testing, however, so perhaps we should reconsider. It's tricky, though: "You keep on using this file, but in this particular repo it does not mean what you think it means..."

Comment by Anton Emelianov (Inactive) [ 15/Jul/19 ]

Taras Tkachenko @stripes-cli (v.1.13.1x) is available at folio-npmci. Are you waiting for the official release?

Comment by Taras Tkachenko [ 24/Jul/19 ]

Tested and proven working.
Thanks.

Comment by Anton Emelianov (Inactive) [ 24/Jul/19 ]

Taras Tkachenko, Excellent! Just making sure that you are OK with closing this issue?

Comment by Taras Tkachenko [ 24/Jul/19 ]

Anton Emelianov yes you can close it for sure.
Great job.

Comment by Anton Emelianov (Inactive) [ 24/Jul/19 ]

John Coburn, Jeffrey Cherewaty, and Zak Burke, Thank you guys for resolving this issue!

Generated at Thu Feb 08 23:18:30 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.