The following comparison tables are useful to understand differences between CicleCI and GitHub Actions services as of Jan 13, 2022. I created this table to ellaborate on the differences between two most used CI SaaS for small/middle size organizations.

TL;DR

  • GitHub Actions and CircleCI have almost same features
  • If you start using CI SaaS today, use GitHub actions
  • If you want to support a monorepo, use GitHub actions
  • If you need huge concurrency capacity but don’t want to manage self-hosted runners, use CircleCI

Feature comparison

Feature Expectation Circle CI GitHub Actions Note
Manual CI execution We can trigger CI jobs by manually outside of CI/CD pipelines. ✅ ✅
CI pipeline visualization We can visualize CI pipelines so we can easily understand status of CI/CD and its dependencies. ✅ ✅
Manual approval We can get approval from some members to deploy code into specific environments. Manual approval feature is useful for those situations. ✅ (ref) ✅
Scheduled jobs We can execute CI pipeline periodically like CRON. ✅ (ref) ✅
Splitting pipeline definitions into multiple files We can put different files per application/project within a single monorepository? ❌ (ref) ✅ CircleCI: hack is necessary to achieve the feature. example1, example2
Self-hosted runner We can use servers on cloud providers to execute CI in addition to CI-provided hosts. ✅ (ref) ✅ (ref) CircleCI: the scale plan is necessary to use this feature.
Parameter matrix We can run the same CI pipelines against different version of software ✅ (ref) ✅ (ref)
Local execution We can execute the same CI pipeline locally when control plane of CI is down but want to execute the pipeline. If we can use the same pipeline definitions in local environment, that is great. ✅ (ref) ✅
Pipeline component ecosystem We can use community efforts to implement CI pipelines. ✅ ✅ GitHub Actions: GitHub Marketplace

CircleCI: Orb
SSH access We can access CI servers to investigate issues in CI. ✅ (ref) ❌ GitHub Actions: hack is necessary to achieve the feature.
File/directory path based pipeline dispatch We can dispatch CI pipelines when related files are changed for each project. 🔺 ✅ (ref) CircleCI: Need to put all workflow configuraitons in a single file if we use monorepo support feature provided by CircleCI.
Concurrency control for pipelines We can run CI pipelines when they are already running. ✅ (ref) GitHub Actions: concurrency control is beta
OIDC support We can use short-live ID tokens to run CI/CD without managing secrets on CI SaaS. ❌ ✅ (ref) GitHub Actions example
CircleCI might release the same feature in 2022 from rumors.

Non-Feature comparison

Non-Feature capability Expectation Circle CI GitHub Actions
Max concurrency We can execute CI pipelines without waiting for other pipeline completions. 80 per account with performance plan and custom per account with scale plan 180 per organization account with Enterprise plan (ref)
Max CI execution time We can use CI pipelines to run long runing tasks. Jobs have a maximum runtime of 5 hours. (ref) Each job in a workflow can run for up to 6 hours of execution time. Each workflow run is limited to 72 hours. If a workflow run reaches this limit, the workflow run is cancelled. cancelled.
API rate limits Self-hosted runner interact with CI APIs There are rate limits - The sales can share the info . For users that belong to a GitHub Enterprise Cloud account, requests made using an OAuth token to resources owned by the same GitHub Enterprise Cloud account have an increased limit of 15,000 requests per hour. When using the built-in GITHUB_TOKEN in GitHub Actions, the rate limit is 1,000 requests per hour per repository. For organizations that belong to a GitHub Enterprise Cloud account, this limit is 15,000 requests per hour per repository. [ref].
Max CI pipeline queue ??? No more than 500 workflow runs can be queued in a 10 second interval per repository.

My conclusion

Although I chose CircleCI as my primary CI SaaS before 2021, I now prefer to use GitHub Actions. GitHub Actions was not so sophosticated and not reliable to use. IMO, it was just a renamed brand of Azure DevOps) running on GitHub. Then, Microsoft and GitHub invested a lot of time and resources for GitHub Actions. As a result, the features are getting better year by year and I believe they will make efforts in the future continuously.

If I pick up some features why I recommend to use GitHub Actions as a first CI SaaS option, the following items come.

  • GitHub Actions enables us to reduce an external tool we need to access (assumingly, we use https://github.com already).
  • GitHub Actions does not need to manage credentials on GitHub repository and GitHub Actions when we use its OIDC integration.
  • GitHub Actions natively supports mono-repository.

I have no doubt that GitHub Actions provides enough features and quality for most of small/mid size organizations. If I can say some requests for Microsoft and GitHub, I’d like them to invest their resources on:

  • Availability
  • Step level pipeline visualizations
  • New contracts to increase CI quotas (e.g. max concurrency)

Then, GitHub Actions will be more promising.