Migrating from Github Actions
On This Page
This document provides an overview of how to migrate from Github Actions to CircleCI.
Why migrate to CircleCI?
CircleCI is a first-class CI tool. CI/CD has been our specialization since the company’s founding 8 years ago. On top of the features you would expect from any CI/CD tool, what sets us apart are the following productivity-boosting features:
Advanced Caching - On top of normal dependency caching, CircleCI offers caching specific to Docker image layers. This means subsequent builds of your Docker images will run faster, cutting even more time off your commit-to-deploy workflows.
SSH Into Builds - CircleCI offers the ability to securely SSH into an execution environment to tail logs, work with files, and directly interact with an environment. This is highly useful for debugging failing builds.
Resource Classes - you can use various different sizes of executor on our platform, great for adjusting according to lighter or heavier workloads on a node.
Test Parallelism - our platform provides not only concurrent job execution but also the ability to split tests between parallel environments. You can dramatically cut build times by splitting workloads between different containers.
Jobs and workflows
Both Github Actions and CircleCI share similar concepts around "jobs" and "workflows". A workflow is an end-to-end flow of connected jobs, which in turn consist of commands to achieve an atomic task (e.g. "run unit tests" or "build a Docker image").
CircleCI differs primarily in configuration syntax, setting up workflow and job dependencies in a separate section as opposed to inline in the job.
Actions vs. orbs
CircleCI offers similar functionality in our orbs. The primary difference is that CircleCI orbs are just packaged, reusable YAML, so you can orbify reusable jobs, executors, or commands, and use them however you see fit in any of your jobs or workflows.
Runners vs. executors
In GitHub, you can specify your builds to run in Linux, macOS, and Windows environments via a
runs-on key in the YAML, and if you want to run anything in a container, you specify an additional
In CircleCI, you have the same choice of environments (called Executors), with additional options and features for Docker.
For each of the executor types, you have a choice of different versions which will subsequently have various versions of base software installed.
See the table in the next section to compare configuration.
|Github Config||CircleCI Config|
Specifying execution environment. While container execution is specified separately in Github,
Specifying dependencies/services. All images specified after the first in CircleCI are treated as dependencies.
Specifying steps to run in a job. Similar functionality, different syntax.
Using shared tasks (Actions for Github, orbs for CircleCI). In CircleCI, you declare orbs at the top level
Using conditional steps in the workflow. CircleCI offers basic conditions on steps (e.g., on_success [default],
Since the configuration between Github Actions and CircleCI is similar, it should be fairly trivial to migrate your jobs and workflows. However, for best chances of success, we recommend migrating over items in the following order:
Help make this document better
This guide, as well as the rest of our docs, are open source and available on GitHub. We welcome your contributions.
- Suggest an edit to this page (please read the contributing guidefirst).
- To report a problem in the documentation, or to submit feedback and comments, please open an issue on GitHub.
- CircleCI is always seeking ways to improve your experience with our platform. If you would like to share feedback, please join our research community.
Our support engineers are available to help with service issues, billing, or account related questions, and can help troubleshoot build configurations. Contact our support engineers by opening a ticket.
You can also visit our support site to find support articles, community forums, and training resources.
CircleCI Documentation by CircleCI is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.