Setting loopback in .airtap.yml breaks local tests

[jhiesey]

I added loopback: airtap.local for use in travis, but this makes local tests not work unless I add airtap.local to my hosts file.

[vweevers]

One option is to use a command line argument instead (--loopback airtap.local). We should update the upgrade guide to reflect this.

Would it make sense to only consider the loopback option if process.env.CI is defined? I.e. don't apply it if running tests locally.

[jhiesey]

My guess is that only using the loopback option when process.env.CI is defined is the right behavior, but I'm not sure if there's another use case for loopback that I don't know about.

For now the command line workaround works for me.

[feross]

I think we should have smart defaults wherever possible, so I'm +1 for only using loopback when on CI. Unless I'm missing some other use case?

Or, to be explicit, what if we rename the option to --loopback-ci?

[vweevers]

There is no other use case, that we know of. So +1 to renaming.

Personally I prefer --ci-loopback, symmetrical to a nested option in YAML:

ci:
  - loopback: airtap.local

Which, random thought, could also mean any option is valid here - as a general way of saying "I only want to apply these when on CI". E.g.:

ci:
  - loopback: airtap.local
  - coverage: false

[vweevers]

Come to think of it, --loopback is not an option for CI per se. It's for Sauce Connect, which you also need when starting Sauce Labs tests from your local machine.