Editor’s note: This post was originally published on August 28, 2014 and was updated on November 29, 2018 for accuracy and comprehensiveness.
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.
Every user and GitHub organization has a total of four free linux containers ($2,400 annual value) for open source projects. By keeping your project public, this will be automatically enabled for you. We also offer the Seed plan free (at 1x concurrency) for macOS open source projects. To get access to this plan, contact firstname.lastname@example.org. Unauthenticated API access is now available for these projects, too, so badges no longer need purpose-specific API keys. Another feature that is great for open source projects is the public build pages for public projects, so your collaborators won’t have to log in to see build pages. For projects that are in orgs with GitHub checks enabled, collaborators can also see the status of CircleCI jobs and workflows in the GitHub UI. Read our blog post on GitHub Checks to learn more about using this feature.
To address specific issues with credentials and settings that are often experienced by developers with open source projects, we have introduced a host of features and settings:
- Private environment variables allow you to safely store secrets for your public project including API tokens, SSH keys, and passwords.
- Only build pull requests to reduce the number of CircleCI builds. By default, CircleCI builds every commit from every branch, which is often too aggressive for open source projects. Toggle this setting on and off in the Advanced Settings of your project.
- Build pull requests from forked repositories to enable tests to run before any manual review, if you allow pull requests from forked repositories. This option can be enabled in your projects Advanced Settings.
- Pass secrets to builds from forked pull requests if you are comfortable sharing secrets with anyone who forks your project and opens a pull request. By default, CircleCI hides four types of configuration data: environment variables, deployment keys and user keys, passphraseless private SSH keys you have added to CircleCI, and AWS permissions and configuration files. Toggle this setting on and off in the Advanced Settings of your project.
Note: If you haven’t already, you’ll need to enable this per-project in Project Settings > Advanced Settings > Free and Open Source. All public projects created from now on will have this set automatically.
If you’re already a CircleCI customer, you’ll see open source builds in the same way you do other builds: it’s in the same app, listed in the same dashboard, using the same API.
All of our features are available to open source customers:
- Our parallelism helps 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.
If you are building a bigger open-source project and need more resources, let us know how we can help you! We’re going to iterate on this, so set up your OSS repos on CircleCI, and let us know what you think!