My Journey from CircleCI to GitHub Actions: The Good, The Bad, and The Workaround
At work, we've always relied on CircleCI for our CI/CD pipelines. Every GitHub repository we created was automatically integrated with CircleCI, which made setting up and managing workflows very straightforward. Over time, I became quite proficient with CircleCI, particularly in writing workflows and debugging them. One feature I loved the most was the ability to re-run jobs with SSH access.
This feature allowed me to SSH directly into the CircleCI runner whenever a job failed, giving me the freedom to explore, make changes, and check if those changes fixed the problem—all in real time. At one point, I even used a remote host and connected via SSH to a CircleCI runner, and from there, I connected to the runner using Visual Studio Code. This setup enabled me to navigate the file system and edit files on the runner directly in VS Code, making debugging a much smoother experience.
However, recently, the company decided we needed to migrate everything to GitHub Actions. This transition was initially quite painful for me, mainly because GitHub Actions didn't offer the same straightforward SSH access for debugging purposes. I felt frustrated because I no longer had the ability to directly look into the runner's environment and troubleshoot issues as I was used to.
On the bright side, I quickly noticed that GitHub Actions also brought some advantages. For example, it seems easier to connect jobs and workflows conditionally. I could set up a workflow that sends a Slack notification whenever another workflow fails—a task that seemed simpler to implement with GitHub Actions than with CircleCI.
Despite these advantages, I still found myself missing the flexibility of CircleCI. The CircleCI UI and command-line tools for validating configs were very intuitive and aligned well with my way of thinking. In contrast, I found the GitHub Actions UI to be quite confusing and not as user-friendly.
Interestingly, I found a workaround that has worked well for me. Our runners are mostly Python-based or Ubuntu-based images, so the environments between CircleCI and GitHub Actions are quite similar. I realized that, while the company hasn't fully deactivated CircleCI, we are just discouraged from using too many CircleCI credits. With this in mind, I started developing and debugging CI jobs in CircleCI, where I could use the SSH debugging feature, and then once everything was running smoothly, I would migrate those jobs back to GitHub Actions.
This approach allowed me to leverage the best of both worlds: the debugging capabilities of CircleCI and the flexible workflows of GitHub Actions. It's not a perfect solution, but it's a pattern that has allowed me to navigate this transition with less frustration.
In conclusion, while I still miss certain aspects of CircleCI, I've learned to adapt and find new ways to work effectively with GitHub Actions. For anyone else going through a similar migration, my advice is to be patient and creative—there's usually a way to make the tools work for you, even if it's not immediately obvious.