Yeah, I've been seeing lots of people switch to circle-ci or gitlab over the past year.
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!
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.
(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!
And yet, here we are... Azure Pipelines
Edit: VS Code too
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...
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.
support@travis-ci.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.
Still independent.
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.