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.
Re:Travis CI acquired by Idera
by williamdclt on Wednesday January 23, 2019 @04:37PM
(#18983300)
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
Yeah, in this case we did though I can see a lot of instances where the benefits don’t outweigh the costs.
Re:Travis CI acquired by Idera
by MapleWalnut on Wednesday January 23, 2019 @12:45PM
(#18980507)
Don't you need to do the same hacking within CircleCI?
Re:Travis CI acquired by Idera
by williamdclt on Wednesday January 23, 2019 @04:39PM
(#18983322)
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
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