testem: Use --no-sandbox on TravisCI#7566
Conversation
rwjblue
left a comment
There was a problem hiding this comment.
I’m 👍 on the change generally speaking (and think we should get a point release out with it), but had one question RE: the specific environment variable used...
| mode: 'ci', | ||
| args: [ | ||
| // --no-sandbox is needed when running Chrome inside a container | ||
| process.env.TRAVIS ? '--no-sandbox' : null, |
There was a problem hiding this comment.
Should we use process.env.CI instead? As I understand it a number of CI providers have this same basic issues (e.g. GitLab CI), and the CI environment flag is pretty universal...
There was a problem hiding this comment.
I'm not sure... GitLab CI can and often does use Docker containers, but you can also run it on real hosts, AppVeyor is likely VM-based, so there are also some CI systems that do not run in containers. The condition is easy enough to adjust if needed 🤔
|
Nice, thanks for looking into this. I figured the sandbox was desirable for some reason? haha oops |
`ember-qunit` is now generating a test of its own which we did not expect before. Updating the expected number of tests fixes our CI runs.
|
FYI I had to include two more commits to make CI pass on the |
Related to use of Headless Chrome, see ember-cli/ember-cli#7566.
Related to use of Headless Chrome, see ember-cli/ember-cli#7566.
Similar to ember-cli/ember-cli-chai#45 this updates the
testem.jsfile of theappblueprint to run Chrome with--no-sandboxwhen used on TravisCI to avoid travis-ci/travis-ci#8836/cc @backspace