Travis & parallelize autogenerated versionCompatibility scenarios

Is there a way to use versionCompatibility with ember try:each and have the jobs run parallel on Travis?

Mirage’s current .travis.yml looks like this and I’m wondering if there’s a way to leverage the autogeneration piece from Ember Try, but still get parallel test runs in Travis.

Alternatively, is there a current “best practice” around these setups? I’m seeing 2 or 3 different configs being used across popular projects.

[rwjblue]

FYI - the issue with linting is not about speed, its about ensuring that the linting runs with the specific versions in your lockfile. When you lint as part of your ember-try config, you end up getting trolled by things like patch releases of prettier/eslint-plugin-node/etc.

[kategengler]

They are pretty fast, but it seems wasteful to lint for every scenario. If you do it as a first stage with a fail fast, you can avoid running any scenarios if linting does fail. To run test without lint, run ember test --query 'nolint'. The first scenario run will be the default which is floated deps, though the rest of the scenarios will run in the ember try:each case; in the travis parallel case it would also fail fast.

On Tue, Aug 14, 2018 at 5:03 PM, Sam Selikoff [e-mail] wrote:

I see.

I think the linting tests are super fast, right? Also, how do you run your ember test suite and ignore the autogenerated linting tests?

I think test:browser is for a fast failure – if the floating deps cause an error I’d want to know after 1 build instead of running all versioned tests. I think I got the idea from Robert. Is it a good idea?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ember-cli/ember-try/issues/202#issuecomment-413015188, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbHOo9ot_05IK22kyN6f8lY0gRGVydiks5uQzsHgaJpZM4V64R4 .