Earlier quoted context omitted.
To (sadly) be fair, Travis has already been struggling mightily with tech debt the last few years. There have been a lot of issues surface and re-surface that sure seem like they shouldn't be a big deal. For example, setting a build to use ruby 2.4 is supposed to run the latest ruby 2.4.x, but would frequently build against ancient, unsupported rubies for a while, before being silently fixed.
They've also been very slow to ship updated machine images— Ubuntu 14.04 wasn't available until late 2015, and 16.04 wasn't until Nov 2018: https://blog.travis-ci.com/2015-10-14-opening-up-ubuntu-trus... https://blog.travis-ci.com/2018-11-08-xenial-release The extremely long lag combined with some communications from Travis developers on related Github issues strongly implied that shipping these was a highly manual p…
I appreciate what they were trying to do with their multiple versions of every language in their stock images. But, in practice there were numerous compatibility problems. If you look at the C++ tickets, you can see how utterly unusable their offering was for this language. From the outside, it looks like they painted themselves into a corner and are mired in technical debt. Quite why it took two and half years to support 16.04 is a question I'd be very interested to know more about.
One solution is to use custom docker images. But that negates any advantages Travis might have had. I can run a docker image anywhere. So when I switched over to GitLab, I use GitLab CI with docker images and custom runners to do fairly comprehensive platform coverage. Something Travis will never do.
They also made a questionable business decision in tying themselves to GitHub. Why no integrations with BitBucket, GitLab, Jenkins, and all the other hosting and automation solutions out there? I had to write Travis off purely because of its lack of availability. The above problems were also an issue, but if it doesn't integrate with your hosting solution, it's a non-starter.