Travis CI slow execution + array.includes is not a function

[alansouzati]

https://travis-ci.org/grommet/grommet/builds/156392643#L1757

In my recent build for Grommet using Jest (:yay) I noticed the following console error:

ERROR: TypeError: config.coverageReporters.includes is not a function
        STACK: TypeError: config.coverageReporters.includes is not a function
    at CoverageReporter.onRunComplete (/home/travis/build/grommet/grommet/node_modules/jest-cli/build/reporters/CoverageReporter.js:70:33)
    at /home/travis/build/grommet/grommet/node_modules/jest-cli/build/TestRunner.js:441:14
    at Array.forEach (native)
    at ReporterDispatcher.onRunComplete (/home/travis/build/grommet/grommet/node_modules/jest-cli/build/TestRunner.js:440:21)
    at /home/travis/build/grommet/grommet/node_modules/jest-cli/build/TestRunner.js:220:33
    at process._tickCallback (internal/process/next_tick.js:103:7)

Maybe we can replace includes by indexOf to avoid compatibility issues?

If you guys agree I can send a PR for that, otherwise what would be the recommended fix for this?

On a side note, I've noticed that my tests are taking a significantly longer time to execute in Travis when comparing to my local system. Is that expected?

This travis job is configured to use Node 5 and Jest test branch.

[boujeepossum]

oh yeah. includes is not available everywhere. indexOf should be totally fine! :)

and travis is significantly slow yes. it is .really. slow :) especially if comparing to macbook pro

[Daniel15]

Are you using the free version of Travis, or the paid version? The free version is pretty resource-limited, so slowness is expected. The paid version has much more CPU power available.

This travis job is configured to use Node 5

As a side note - Node v5 is EOL... v4 is the LTS release and v6 is the 'current' release. You should switch to either v4 or v6 depending on whether you want a release with long-term support (v4) or a release with the latest features (v6)

[alansouzati]

Thanks for the heads up on v5, I will make sure to update it. I'm not worried about being slow, just wanted to make sure I was not doing anything wrong.

I'm going to work on the PR for the includes issues

[cpojer]

I'm fixing the includes issue.

[eddywashere]

Re: Travis Slow execution, I found that using the --runInBand helps in an environment with limited resources.

[mareksuscak]

Just FYI: Tests on Circle CI were extremely slow too in our case. 4s on local machine vs more than 90 seconds on CircleCI. Using --runInBand switch reduced it to 45s which is 50% improvement.

[kentcdodds]

I can verify that --runInBand took our tests from >1.5 hours (actually I don't know how long because Jenkins timed out at 1.5 hours) to around 4 minutes. 😱 (Note: we have really poor resources for our build server)

[rrcobb]

We probably have memory leaks in our tests, but another helpful fix for running specs in docker was the node flag --max_old_space_size.

karma (running in an x-window for the sake of running headless Chrome), for comparison:

$ time xvfb-run node --max_old_space_size=4096 ./node_modules/.bin/karma start --browsers Chrome_without_sandbox
...
real    2m8.409s
user    1m37.480s
sys     0m14.380s

jest with max_old_space_size only

$ time node --max_old_space_size=4096 ./node_modules/.bin/jest spec/javascripts
...
real    3m54.833s
user    3m4.110s
sys     0m23.450s

jest with --runInBand only

$ time node ./node_modules/.bin/jest spec/javascripts --runInBand
...
(crashes with a GC error)

jest with both --runInBand and --max_old_space_size

$ time node --max_old_space_size=4096 ./node_modules/.bin/jest spec/javascripts --runInBand
...

real    3m40.529s
user    2m48.980s
sys     0m22.580s

Our speed would probably be helped most by addressing memory leaks, but wanted to leave the trail in case someone else found it useful.