How to migrate CI build from Travis to GitHub Actions

This guide contains instructions about how to migrate CI builds from Travis to GitHub Actions.

1. Using the terminal navigate to the root of the repository.

2. Create a branch based off the master branch and switch to it.

3. Delete the .travis.yml file to stop Travis from executing the CI builds.

4. Create a workflows directory in the .github directory and add a <name>.yml file with a name of your own choice. GitHub looks for this file in this directory, and if present, it processes the instructions that it contains.

5. Understand the instruction that the .travis.yml contained and then refer to the Migrating from Travis CI to GitHub Actions page and the various resources that it provides to translate them to instructions that GitHub actions will understand. The below basic workflow template provided by GitHub gives an explanation of some of the most common instructions. It is recommended that you start small by setting up and getting the basics right i.e. specifying when the builds will need to run using the on label, the OS that the build will run on, and finally configuring it to run a simple job like lint for example.

   name: CI
   
   # Controls when the action will run. 
   on:
     # Triggers the workflow on push or pull request events but only for the master branch
     push:
       branches: [ master ]
     pull_request:
       branches: [ master ]
   
     # Allows you to run this workflow manually from the Actions tab
     workflow_dispatch:
   
   # A workflow run is made up of one or more jobs that can run sequentially or in parallel
   jobs:
     # This workflow contains a single job called "build"
     build:
       # The type of runner that the job will run on
       runs-on: ubuntu-latest
   
       # Steps represent a sequence of tasks that will be executed as part of the job
       steps:
         # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
         - uses: actions/checkout@v2
   
         # Runs a single command using the runners shell
         - name: Run a one-line script
           run: echo Hello, world!
   
         # Runs a set of commands using the runners shell
         - name: Run a multi-line script
           run: |
             echo Add other actions to build,
             echo test, and deploy your project.

6. To be able to test your configuration without having to create a pull request, make sure that the on label contains the push event type. This will trigger the CI build each time a commit is pushed to the remote branch.

7. Once you are happy with your configuration, commit your changes and push them to the remote branch.

8. Navigate to the Actions tab of the GitHub repository to see the build. ✔️ will be displayed if the build succeeded, or ❌ if it failed.

9. Keep on making changes to the .yml file and pushing them until you are happy with the outcome.

10. Once you are happy with everything and before making a pull request, go back and configure the on label to look like below. This will ensure that the CI build is not triggered each time a commit is pushed but rather when a pull request is opened, and when it is merged into master. The CI build will still be triggered when a commit is pushed to an opened pull request.

    on: 
      pull_request:
      # By default, the pull_request event type is not triggered when a PR is merged into master
      push:
        branches:
          - master

Useful resources:

• GitHub Actions Guides
• Caching Dependencies Examples