Migrating from TravisCI to Github Actions

Every project needs CI and there are many solutions to choose from. We'll compare two of them by describing our journey migrating from TravisCI to GitHub Actions.

What even are these tools?

Both TravisCI and GitHub Actions are continuous integration services. Continuous Integration (CI) requires developers to frequently integrate code into a shared repository. Each change is verified by automated tools — linting, tests, and builds — catching problems early.

CI can be paired with Continuous Delivery (CD), which ensures software can be deployed at any time. Automate the release process further and you get continuous deployment.

Why are we changing?

TravisCI Startup

$129/month — unlimited build time, up to 2 concurrent jobs

GitHub Actions (with Team)

Included in $88/month GitHub Team — 10,000 minutes, up to 60 concurrent jobs

We were using about 5,500 minutes of builds per month — well within GitHub’s free limit. Even paying for all that time would cost only $44. The decision was simple.

What was easy?

Both tools are similar in concept: do a couple of things when something happens and report the results. For both tools, specifying what happens is done via special YAML files stored in the repository along with the project source code. Setting when something happens on TravisCI is done by pushing the correct button on the website. That’s different for Github Actions: you set it in the YAML configuration file.

The concept of determining what to do and in which order is similar in both tools, but the implementation is different. In TravisCI, you can add blocks of code to predefined steps that are executed in a specific order. In Github Actions, you can create any number of actions, which contain jobs with inside steps (blocks of code). We created one action that is composed of three jobs: testing, building, and deployment. Contents of TravisCI steps were distributed among these jobs in a form of steps. Focusing deployment step only on specific branches and parametrizing target was easy because both platforms support conditional step execution in their configuration format.

Specifying the required environment is also similar — set languages and versions in the config file and everything is taken care of. Both platforms support multiple operating systems and matrix builds. One difference: repository contents are always available in TravisCI, but GitHub Actions requires an explicit checkout step.

Handling secrets works the same way — create them on the website and they become environment variables in the build. Both tools sanitize output by censoring secrets if printed.

The build badge was also straightforward to migrate. Both platforms expose build status as an image URL you can embed in READMEs and Slack channels.

What wasn’t easy?

Not everything is 100% compatible. Here are the issues we hit:

Branch Name

TravisCI has `BRANCH`. GitHub Actions has `GITHUB_REF` which includes extra data — we had to extract the branch name from the ref string.

Build Number

TravisCI provides `TRAVIS_BUILD_NUMBER`. GitHub Actions has no equivalent — we count commits on the branch instead.

Passing Values Between Steps

Each step runs in a separate environment. The workaround: print values to stdout in a specific format to set global env vars.

No Build Debugging

TravisCI lets you SSH into a failed build. GitHub Actions had no equivalent — we resorted to printf-debugging.

At the time of writing, GitHub Actions lacked automatic build cancellation. In TravisCI, pushing a new commit cancels the in-progress build on the same branch. GitHub Actions ran all builds, wasting minutes on intermediate commits.