[williamdclt]

We usually use CircleCI at my company. I never realised how good I had it until I had to use Travis at my current project :)

To give an example: we have a monorepo and it's impossible to only run the tests of the project that has been updated. Even if you're ready to hack around with git. Even if you're ready to hack around with Travis internal functions. Because TRAVIS_COMMIT_RANGE is just broken.

And your argument "people switch to circle-ci, not sure why, Travis does what I need and I know how to use it" doesn't really make sense, other people would say that CircleCI does what they need and they know how to use it

[mnutt]

We also use travis + a monorepo and yeah TRAVIS_COMMIT_RANGE is broken. We end up just tagging successful master builds and generating our commit range off of that.

But yeah, so much of it is flaky, and the pricing is noncompetitive. Our current iteration has travis's docker client tunneling to an ec2-based docker server; it's both cheaper and faster and will hopefully make it easier to rip out Travis in the future.

[williamdclt]

Not a bad idea but travis only does a shallow clone, do you unshallow it? Doing a `git fetch --unshallow` was slow, and hanging forever about one time out of 5 when I tried a few weeks back

[mnutt]

Yeah, in this case we did though I can see a lot of instances where the benefits don’t outweigh the costs.

[MapleWalnut]

Don't you need to do the same hacking within CircleCI?

[williamdclt]

I do, but at least it is feasible (at least I think, never actually needed to do it). With Travis, even being willing to hack around, I just didn't manage to get it working at all