Setting env var `BROWSER_PROVIDER` to `browserstack` or `saucelabs`
determines which browser provider will be used.
This does not affect the build as all jobs are set to use SauceLabs.
Switch to Karma with Socket.io 1.x, which solves some issues(*) with BS.
Thus removing `config.transports` as it is not used anymore
(Socket.io 1.x starts with polling and tries to upgrade if available).
(*) folks from BS were fiddling with socket.io configuration to get it stable.
See 4c04011850
This is not necessary with Socket.io 1.x.
We’ve seen many failures recently because of Karma killing a browser
after browserNoActivityTimeout. It’s possible that this is not any issue
other than super slow network / proxy.
Will try higher timeout and observe for a while.
I think we are pretty close to be able to use both.
The xhr-polling seems to be pretty stable, but I'm having problems with multiple SSH tunnels (on BS), so let's try to switch back to SL.
Also instead of running everything in parallel, there are only two parallel tasks:
- e2e tests running in the background (only on Chrome)
- all the unit tests running sequentially
- parallelize the tasks
- cache requests (e2e tests)
This reduces the time from ~18min to ~12min.
It makes the output little messy. We could buffer output of each task and display it once it's fully finished, nicely. I think giving instant feedback is better.
This should not affect the Jenkins build at all.
Now, the Travis build uses Chrome on Sauce Labs, which in theory gives us opportunity to use any
browser/platform that Sauce Labs offers.
