We started CircleCI as a way to help development teams to be more productive. As part of that, we’ve long focused on tooling for production web applications, and most of CircleCI’s feature set is aimed at letting teams ship code faster.
This means we haven’t focused on building features for open source repositories, and our customers have had trouble sharing build results with collaborators or have even resorted to using different services. You’ve asked us for a long time to provide better support for public projects, and we’re happy to announce some features in that line today.
From now on, every user and GitHub organization has three free containers to build public projects. We also now have public build pages for public projects, so your collaborators won’t have to log in to see build pages. Unauthenticated API access is now available for these projects, too, so badges no longer need purpose-specific API keys.
One note – if you haven’t already, you’ll need to enable this per-project in Project Settings > Experimental Settings > Free and Open Source. All public projects created from now on will have this set automatically.
Principally, if you’re already a CircleCI customer, you’ll see open source builds in the same way you do other builds: its in the same app, listed in the same dashboard, using the same API.
Naturally, all of our features are available to open source customers:
Our parallelism and automatic test splitting help your test suite grow faster than your build times.
We have a nice mechanism built-in for saving and uploading build artifacts .
You can SSH into our builds to figure out what’s gone wrong, when your tests do fail. :)
Our infrastructure scales up automatically, so you should never experience any busy times or queueing times due to others.
…but this is an early version.
Bear in mind that this is an early version to help our existing customers. As a result, we are currently missing a few features that might be important to you, and that you might want to wait for:
CircleCI is mainly focused on building your project against one canonical set of language and dependency versions. We can’t yet show you a comprehensive pass/fail matrix for dependency combinations. We know this can be a dealbreaker especially for open-source libraries, and it’s on our radar.
We only have experimental support for building pull requests from forks automatically – there are some weird edge cases, and it’s hard to find a model of sharing settings that works right. (If you’d like to try what we have, it’s available in Project Settings > Experiment Settings as well).
We ask for access to private repos when you sign up, whereas we should only ask for public repos. We’re changing that too.
Finally, our UI is tuned to private projects, so it may be unpolished and confusing in places for public ones. Let us know if anything like this bugs you!
We’re going to iterate on this, so set up your OSS repos on CircleCI, and let us know what you think!