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.
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
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)
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
I'm fixing the includes issue.
Re: Travis Slow execution, I found that using the --runInBand
helps in an environment with limited resources.
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.
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)
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.
Try to set the Travis CI node version to 10
and use --runInBand
rather than --maxWorkers
in the jest test cmd. We are having 809 test suites in our project and reduced from 2hrs with the timeout error to 45 mins.
Most helpful comment
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)