Don't enable SimpleCov in CI

[geoff2k]

While working on #123, a number of my builds segfaulted and failed during their runs under Travis (example 1). I investigated and noticed that segfaults appear to occur sporadically in other builds that did not contain my code: example2, example 3.

I have been unable to reproduce the segfaults locally under any of the versions of Ruby we test with. 😞

Per google searches, SimpleCov seems to be anecdotally related to segmentation faults experienced running builds in CI, so this PR checks for a well-known environment variable CI (supported under both Travis and CircleCI) and doesn't enable SimpleCov if present.

If this does not solve the issue, we may need to use something like travis-codedump to diagnose the segfaults.

[mensfeld]

I have a similar problem - but that is not because of simplecov. That's due to some issues with FFI and Rubys GC. There were some bypasses suggested (including by me) but they don't seem to work in all the scenarios.

[geoff2k]

@mensfeld In your estimation, are these worth trying to track down? In other words, while the failures in CI are annoying, I'd be more willing to ignore them if we knew they didn't point to some problem with the code under test, if that makes sense.

[Adithya-copart]

@geoff2k I ran into similar issues while open sockets are closed during the shutdown sequence.

See #108 (comment) and CI run.

I ended up calling close in the specs where sockets were left open after some debugging at that time.

[mensfeld]

@mensfeld In your estimation, are these worth trying to track down? In other words, while the failures in CI are annoying, I'd be more willing to ignore them if we knew they didn't point to some problem with the code under test, if that makes sense.

The question here is: will it occur in production. And the answer is: I don't know. I took several countermeasures to make sure it won't happen in production (in Waterdrop). I tackled majority of cases in specs as well but there's still something off.

I've been running Waterdrop 2.0 (with rdkafka) in scale of up to 10k rq/s with auto-scaling on aws and things that could potentially trigger this as well as with instrumentation to detect something like that upon process exit and for the past several months it never occured anywhere beyond CI.

However, I still see this as an issue worth investigating.

[thijsc]

I've been running Waterdrop 2.0 (with rdkafka) in scale of up to 10k rq/s with auto-scaling on aws and things that could potentially trigger this as well as with instrumentation to detect something like that upon process exit and for the past several months it never occured anywhere beyond CI.
However, I still see this as an issue worth investigating.

Same for us, we run this in production and have never once seen it happen. Still unsure why the spec context matters so much. Probably because in production you never close and recreate consumers/producers.