Improve Travis CI build stability

[waryhermit]

We have had a streak of Travis CI build errors, must of which have not been code issues but configuration and dependency issues.

• [x] [IMPLEMENTED] We can mitigate random npm errors somewhat with the following two ideas:
  • [x] Make Travis cache the npm packages by adding the following to the travis.yml:

    cache:
    directories:
    - $(npm root -g)
    - node_modules

  • [x] change npm install ... to travis_retry npm install ... which will retry up to 3 times be default.
• [ ] [IN PROGRESS] We can reduce dependencies by migrating the rest of the python tests to js so we only have js dependencies
• [ ] [ON HOLD] We can reduce errors caused by dependencies changing any of the following:
  • [ ] Specify a certain version when using npm
  • [x] Use npm shrinkwrap or yarn.lock to keep dependencies the same as the local tests. (Implemented see https://github.com/ole-vi/BeLL-Apps/pull/93 )
• [ ] [IN PROGRESS] We can add automatic retries to codeceptjs tests so that tests that randomly fail don't make the whole build fail.
  • [ ] (This might cover up problems.. 1 random failure for a test out of 100 probably isn't a problem, but 1 out of 10 probably would be.) UPDATE: I will limit the retries to 2 or 3, shouldn't cover up many issues that way.

[waryhermit]

Might also want to make some of the script tests @dogi made to be allowed to fail: https://docs.travis-ci.com/user/customizing-the-build#Rows-that-are-Allowed-to-Fail

[dogi]

@waryhermit awesome - lets do this

[waryhermit]

Yarn doesn't intend to replace npm, more like improving on it. It uses the same package.json file, and saves dependencies to the node_modules/ folder. You can read about some of the benefits of yarn here. The two features I think will make the most difference for us are:

• Deterministic: The same dependencies will be installed the same exact way across every machine regardless of install order.
• Flat Mode: Resolve mismatching versions of dependencies to a single version to avoid creating duplicates.

To start the process of switching to yarns method of resolving dependencies I made sure all our packages were listed in package.json, deleted the node_modules folder and then ran yarn to rebuild the node_modules in the yarn way.

In order obtain the benefits of yarn, everyone adding dependencies should use yarn. They can still use npm - but then we will still be in the same situation as before. Nothing will break, but we will have the same problems we have right now.

There are a zillion ways of installing yarn. The commands are almost exactly the same as npm, see Migrating from npm. Adding node_modules to .gitignore will help keep our pull requests clean.

As far as deployments go - all that should need to be done is include the node_modules in the .zip and installer .exe. For the inno installer, that should be as simple as running a few yarn commands during the build script and making sure the node_modules folder is listed in the folders to include. I imagine it would be the same for the legacy deployment script.

Do you want me to make pull requests to update to build scripts before this pull request is merged with ole-BeLL-Apps ?

[waryhermit]

Putting all yarn stuff on hold for now since @dogi does not feel this is a good time.

[waryhermit]

I am 3/4 of the way through converting all the python tests to js and adding retries.