I didn't think of Travis in that regard, though in a past few month I started to see Circle CI badges popping here and there for opensource repositories and anecdotally many internal projects at companies are moving to GitLab and their built-in CI offering.
Probably a good time to sell the company, though I'd prefer if they would find a better buyer.
* this is a comment from me personally and not an official company statement.
Not totally sure why. Travis does what I need and I know how to use it, and I don't particularly want to learn something new for CI myself, I just want to code!
1 - As little as $2/month, apparently.
Circle has some nice features (especially easy artifacting and splitting rspec tests based on historic run-time) but it's not enough to overcome the lost momentum and productivity of being unable to reach the web interface.
I've been very happy with Buildkite so far. The web interface fits my mental model of how things should work much better than CircleCI's ever did.
Our primary reason for switching was CircleCI's unpredictable and high costs on the iOS side (per minute billing combined with slow builds -> monthly fees in the price range of a new Mac mini).
Our Android builds are now about 10 times as fast at the same price.
The savings and the performance benefits are of course wholly due to the bring-your-own-build-machines approach that Buildkite takes. I don't see that as much of a hardship, though, especially since CircleCI 2.0 removed a lot of the "it just works" magic in favor of your own build scripts and Docker images. Preparing the build agents is not significantly more work.
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
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.
It's very "power user" in that it's easy to get lost amongst all the options, but nothing else I've tried has the same breadth of OSes and ability to have one job depend on another in intricate ways. And, 10 free parallel builds, including macOS!
Also, hosted agents have small inconsistencies that make the pipeline to have ton of do this on Linux but not in OS X or windows and so forth...
And yet, here we are... Azure Pipelines
Edit: VS Code too
(Yeah, I know, all these CI things are hypothetically platform agnostic, but then there's reality, different platforms-under-test have different sorts of problems which become priorities for the CI platform to smooth out and make just work, or don't).
But Azure is def on my list to check out!
We can do it on .org as well! Just need to reach out to us via email to enable it (as well as the instructions, as it requires a manual API call rather than a UI Button.) And, as Involans also mentioned, we are merging the two together.
email@example.com And we'll set you right up with debug mode. :)
Builds were taking up to 20 minutes and with multiple team members doing prs, it was quite common to be stuck waiting for things to land to our integration environment. This slowed us down a lot and we fixed it by creating a build pipeline in amazon. In there we were able to pick one of their faster instance types and the exact same build ran in something like 5 minutes. I understand the team moved to gitlab pipelines after I left.
I was just discussing this with a guy that works at codeship, a berlin company that was acquired some time ago that creates build tools. He made the point that tools like that are getting replaced by deep pipeline integrations like provided by Gitlab.
There is a need for tight integration between build pipelines, version control systems, issue trackers, alerting, monitoring, cloud providers, kubernetes, etc. You can sort of do this partially but you typically have to deal with gazillions of SAAS solutions of varying quality that typically don't integrate that well and the devops related to that. E.g. making Jira aware of github PRs and build status in jenkins can probably be done but you are dealing with API tokens, access rights, and wonky webhooks, credit card payments, etc. The overhead of setting all of that up for every team is quite high and I've seen teams cut corners here because they have more important/interesting things to do. E.g. typical Jira setups have typically no meaningful integrations with either ci or version control systems. Even well run projects tend to have non trivial amounts of devops related time and cost to manage all this. Many projects simply start by copying whatever they did last time that wasn't completely horrible.
IMHO, this is potentially something MS could get right simply by creating deep integrations between e.g. Azure, Gitlab, and a few other things they own. IMHO, amazon is lacking a few things in their portfolio and it wouldn't surprise me to see them make a move either by launching or acquiring their own things. Google is another company that is missing a few essential things on this front.
For one of my projects, I have TravisCI building release binaries for Windows, Linux, and macOS.
Of course that doesn't explain why open source projects would switch, but it could just be a mind share thing.
Fine for startups I guess. For the use case of someone who wants a CI server that, say, runs tests on their Project Euler private repo it's a no-way-no-how price point.
I assume they've thought this through and it's done purposefully. Still, side projects tools are a gateway to real project usage.
Here is example for Travis CI
And this is the graph showing the difference if you compare knapsack_pro dynamic tests split with what CircleCI does which is basically only time-based split.
I dread when I have to tweak things. I do appreciate the service(s) a lot though. Pipelines is one of the better CI/CD platforms I've ever used anywhere. It's just, like you said, sometimes hard wrt documentation.
I hear Appveyor and Azure Pipelines are the two most usable Windows build systems; I'm quite happy on Appveyor.
Doing better than me. Only inertia keeps me on Appveyor. Once I have time to look into Azure Pipelines, I'm off Appveyor for my Rust projects.
At least for open source, Appveyor builds are serial (across all of my projects?) and you have to (had to?) go through hoops to setup cron triggers.
For serial builds, it is so bad, half the time I give up waiting and just submit.
For cron, I only care about scheduling about once a month or so to double check none of the tools I rely on break so contributors aren't the first to see them and have a negative experience.
From my perspective, it's been interesting to see how people do. Some people bring all of their builds, of course, but some people split it up so that it's a mix of Azure Pipelines and Travis (or, of course, something else). Some people are bringing one or two platforms over - maybe they had Travis working as their build validation system, but it was doing Linux builds. So adding Windows builds with Azure Pipelines made sense. Or they wanted to do macOS or iOS builds, so they started building on our macOS build agents.
Anyway, I'm happy for Travis and I'm glad to see that they're excited about this acquisition. I can speak from first hand experience that running builds for open source projects takes a lot of resources. So I trust that this will help them make sure that they're in a position to continue helping out the open source projects and communities.
It's not as fancy as the abstracted editors that have their own non-DOM format structure but they usually are missing many other features.
The pricing has increased and the hobby plan probably isn't worth it but the product itself is good if you need an editor.
GitLab vs CircleCI: https://about.gitlab.com/devops-tools/circle-ci-vs-gitlab.ht...
GitLab vs TravisCI: https://about.gitlab.com/devops-tools/travis-ci-vs-gitlab.ht...