LCTT’s CI has been running on Travis CI for many years, consistently providing a good use experience. Since GitHub launched its own CI tool, GitHub Action, in 2019, we’ve been considering moving CI from Travis-Ci to GitHub to reduce maintenance and communication costs. And with the help of GitHub Action Marketplace to achieve more powerful capabilities.

Recently, we migrated CI from TravisCI to GitHub Action due to a number of deployment errors and the fact that our account had exceeded the free usage limit due to heavy usage.

Project introduction

The Translate Project is a major collaboration of the LCTT Translation Group, where hundreds of translators use GitHub to Translate articles around open source, Linux, software engineering, and more. Since 2013, a large number of submissions have accumulated, resulting in a large number of files under the Project.

Translate Project uses CI to help translators check basic text formats and pull requests; And regular execution of the command, to carry out all the application check, for the overtime did not complete the translation of the work for recovery; The status of the article is marked and the corresponding badge is generated.

Migration way of thinking

The overall difference in usage between Travis CI and GitHub Action is not that great, as both write configuration files based on the YAML file format. However, unlike Travis CI, GitHub Action supports multiple profiles, so you can configure different profiles for different scenarios, reducing the complexity of a single configuration file.

In addition, since our script relies on some Travis CI environment variables, we also need to replace them with the corresponding environment variables in GitHub Action to make sure the script works.

Reforming practice

1. Analyze the previous CI process

Our CI profile on TravisCI is shown here

The whole thing can be divided into three parts:

  1. Command area: Indicates what is done during the installation phase and the execution phase
  2. Condition area: Specifies the conditions under which this profile will take effect
  3. Deployment area: Does it specify how build artifacts are deployed

In the command area, there are preset installation procedures and subsequent execution procedures. During the installation process, some dependencies are installed and the current Pages resource is cloned locally to inherit the data generated from the last build.

In the condition section, only the master branch is specified

In the deployment area, the result of the previous command area is deployed.

In the actual execution process, it will decide whether to execute specific commands according to different environment variables. This part can be adjusted and split into different files in the subsequent transformation process.

2. Apply the configuration file directly

After completing the basic analysis, you are ready to create the new Action profile. Because the basic syntax is similar, many of them can be applied directly.

For example, when our configuration file is applied directly, the result is as follows

The directly applied files are already working, but there are a lot of unmet needs, so some changes are needed.

3. Restore the Travis CI environment variable

Since I didn’t write the generated script like Badge that we used, there is no intention to adjust the alignment to avoid failures in this migration. The script relies on some variables that need to be reset.

GitHub Action provides methods for setting environment variables manually. You can set the TRAVIS_BRANCH and TRAVIS_EVENT_TYPE environment variables in your build environment by adding the following code to your build steps to ensure that you can use this environment variable.

 - name: Set ENV variables
        run: |
          echo "::set-env name=TRAVIS_BRANCH::${TRAVIS_BRANCH:-$(echo $GITHUB_REF | awk 'BEGIN { FS = "/" } ; { print $3 }')}" 
          echo "::set-env name=TRAVIS_EVENT_TYPE::$(if [ "schedule" == "${{ github.event_name }}" ]; then echo "cron"; else echo "${{ github.event_name }}"; fi)"

Also, since set-env is a relatively dangerous method, you need to enable execution of dangerous functions in environment variables.

    runs-on: ubuntu-latest

4. Split the configuration file

One difference between GitHub Action and Travisci is that you can split your CI files into multiple files, reducing the complexity of each individual configuration file.

According to the above analysis of the process, our CI process can be divided into three parts:

  1. generatebadgeDocumentation should follow each submission
  2. generatestatusFile, the execution time is longer, can be regularly executed
  3. According to the pull request content to sort out, do the verification

We split our configuration file into three different files:

Also thanks to the split, some of the necessary dependencies are not installed in the Checker, streamlining the CI process and improving the CI execution time.

5. Test the operation of CI

After the configuration file is written and split, you can perform local execution tests. Once the GitHub Action is written, it is inevitable to execute it to make sure the whole process is in order.

This time you can install tool (, to execute the Action at the local, to confirm that your code is correct.

If you are on MacOS, you can install the ACT tool by simply executing BREW INSTALL ACT to complete the installation of ACT.

Once act is installed, you can execute actions locally by executing the act command, for example, by executing act pull_request to trigger a GitHub pull request event

Once you’ve passed your local tests, push your configuration file to GitHub for production testing.

6. Remove the Travis – CI

After completing the migration from Travis CI to GitHub Action with the steps described above, we can remove the.travis.yml file in the project root and close Travis CI completely.

7. Replace environment variables

After the basic migration, you need to fix some of the historical issues in your code. In the third step, we replaced the environment variables for travis-ci, but long-term maintenance projects should try to replace the uncontextual information with documented information, so we need to replace it.

Replacing the environment variable depends on the GitHub official environment variable description. You can refer to the official documentation.

With this simplification, the configuration file has been reduced from 27 lines to 17 lines, making it much simpler and easier to understand.

8. Modify the branch protection conditions for GitHub

In order to ensure that the changes meet the standards, we have restricted that new pull requests must pass the CI check before they can be merged into the master branch, so we also need to modify the branch protection rules to ensure that the appropriate protection is set.

A few considerations

1. Different environment variables

If you rely on environment variables, you will need to modify them accordingly. Or you can do what I did by having temporary environment variables locally first through set-env and then gradually migrating them later.

2. Action dependencies should be safe to run

There are two parts to the Action execution. The Action process itself depends on the master branch, but the script called during execution depends on the source, so from a security perspective, you should try to put all the processes in the Action, rather than in your source directory.

3. How to trigger the CI Pull Request check?

As you test the Pull Request, you need to trigger different Commit over and over again, You can Trigger a blank commit by executing Git Commit — Allow-Empty-M “Trigger Notification “&& Git push. After you push it to GitHub, Then the construction of the pull request can be triggered again to improve the efficiency of construction.


Through the TravisCI process cleanup, code modification, and so on, we migrated our previous travis-ci to a faster, better performing GitHub Action, which on the one hand optimized our workflow and on the other hand made our code cleaner and cleaner.

For projects that are still using Travis CI, consider migrating to GitHub Action to optimize your workflow.

Refer to the reading