-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added iOS and Android to unit tests #2538
Conversation
cf557e5
to
72a3d3e
Compare
It would be great if we can figure out how we can allow the browser to restart a set number of time before having it fail the build. This PR LGTM, though. |
I haven't found that the tests are flaky enough in BrowserStack to require actual retries. The BrowserStack plugin retries 3 times by default but gives a warning each time it needs to retry which is what causes the task to fail without --force. |
Ah, so we need to make grunt not fail on a warning. |
We could use grunt-force-task to not fail on warnings. |
Sounds interesting but seems like that will make errors not fail either then, no? |
Maybe this will help? https://www.npmjs.com/package/grunt-passfail#options-ignorewarn |
Looks like you're right about force covering up failures (failed build). grunt-passfail makes me a little worried because the github link is broken. I think we could handle the retries in another PR. They shouldn't happen with the way the timeouts are setup in this PR. |
Yes, the retries thing should definitely not hold up this PR. |
Looks like it's on github but the url is wrong: https://github.com/sfrdmn/grunt-passfail |
Should we wait to figure this out or pull this in now? |
I think we should pull this PR in. We can figure out how not to fail on warnings another time. |
This PR is to add Android and iOS as browsers for the unit tests. For some reason the BrowserStack tunnel isn't working correctly when using a 5.0 Android VM so I have targeted 4.4.
I have also increased the timeouts to handle all this testing. All the browser VMs start simultaneously which means that if a VM doesn't start its testing before the capture timeout or no activity timeout is hit then it will give a warning, restart the browser VM and fail the build in the end. To avoid this the timeouts need to be bumped up to account for the total testing time. Polling timeout was also bumped up to avoid hitting the API rate limit.
This closes #2512 and closes #2529