Migrating from Travis CI to GitHub Actions

README.md

Migrating form Travis CI to Github Actions

Although Travis CI and GitHub Actions do similar things, they do not always do them in the same way. There is a document in the GitHub mnaual about Migrating from Travis CI to GitHub Actions but it is rather sparse.

This document offers a more complete guide of how to do things in GitHub Actions (GHA) when coming from Travis.

The following things from Travis CI are described:

• addons

• after_deploy after_script before_deploy before_install before_script deploy install script (all from Job Lifecycle)

• after_failure, after_success (both from Job Lifecycle), and TRAVIS_TEST_RESULT (from Environment Variables)

• fast_finish (from Build Matrix)

• TRAVIS_BUILD_DIR ${{ github.workspace }}

• TRAVIS_COMMIT ${{ github.sha }}

addons

The addons entry in Travis is used to install dependencies, configure external services (such as Browserstack, CodeClimate, CoverityScan, SourceConnect, Sonarcloud, and SourceClear), and influence the build environment (build artifacts, set the hostname, add entries to /etc/hosts or ~/.ssh/known_hosts).

Installing dependencies

In Travis, several packages can be listed directly:

addons:
  - chrome
  - firefox
  - mariadb
  - postgresql
  - rethinkdb

Beyond these whitelisted packages, apt, homebrew, or snaps entries can be used to install packages, for example:

addons:
  apt:
    packages:
      - some-package

For GitHub Actions, there are three ways to deal with dependencies:

1. The dependency might already be installed
2. Using a Docker image containing the dependency
3. Install the dependency using apt (or something similar)

Already installed dependencies

A lot of software is already installed on the used platforms (macOS, Ubuntu, Windows Server) by default. Check the Supported software section to see what is already available. the most common dependencies on Travis are most likely already present in GitHub Actions.

Docker images

If a dependency is not already present, a Docker image can be used which does contain the needed software, for example:

jobs:
  some-job:
    services:
      mysql:
        image: mariadb:10.5
        env:
          MYSQL_ROOT_PASSWORD: password
    steps:
      - name: Verify MySQL connection from host
        run: |
          mysql --host 127.0.0.1 --port 3306 -uroot -ppassword -e "SHOW DATABASES"

Install

As a last resort, use apt install, or an equivalent command to install the dependency.

jobs:
  some-job:
    steps:
      - run: sudo apt-get install libxml2-utils

External services

In the GitHub Action Marketplace, actions are available for many external services. For instance BrowserStack:

jobs:
  some-job:
    steps:
      - uses: 'browserstack/github-actions@master'
        with:
          username:  ${{ secrets.BROWSERSTACK_USERNAME }}
          access-key: ${{ secrets.BROWSERSTACK_ACCESS_KEY }}
          build-name: BUILD_INFO
          project-name: REPO_NAME

For any service that does not already have an action, a docker image could be used, or an action created.

Build environment

Manipulating the build environment (building artifacts, setting the hostname, add ing entries to /etc/hosts or ~/.ssh/known_hosts) can be done either through adding steps to do so, by creating a docker image that already has the changes needed, or by using Docker Compose:

jobs:
  some-job:
    steps:
    - uses: actions/checkout@v2
    - run: docker-compose -f docker-compose.yml up -d
    - run: docker exec my_container

after_deploy, after_script, before_deploy, before_install, before_script, deploy, install, script

Github Actions doesn't really have the concept of Job Lifecycle that Travis does.

So instead of after_deploy, after_script, before_deploy, before_install, before_script, deploy, install, script, everything in GHA everything is "just" a step.

So, instead of this (in Travis):

before_install:
  - some_command
install:
  - some_command
before_script:
  - some_command
script:
  - some_command
after_script:
  - some_command
before_deploy:
  - some_command
deploy:
  - some_command
after_deploy:
  - some_command

jobs:
  build:
    steps:
      - name: before_install
        run: some_command
      - name: install
          run: some_command
      - name: before_script
          run: some_command
      - name: script
          run: some_command
      - name: after_script
          run: some_command
      - name: before_deploy
          run: some_command
      - name: deploy
          run: some_command
      - name: after_deploy
          run: some_command

Source(s):

after_failure, after_success, and TRAVIS_TEST_RESULT

To run logic Travis after a build has failed or succeeded, one would use:

after_failure:
  - some_command

after_success:
  - some_command

The same can be achieved in GHA by combining if and a status check function:

jobs:
  some-job:
    steps:
      ...
      - name: after_failure
        if: ${{ failure() }}
        run: some_command

      - name: after_success
        if: ${{ success() }}
        run: some_command

Besides failure() and success(), GHA also offers always() and cancelled().

The status of the build TRAVIS_TEST_RESULT job.status (Possible values are success, failure, or cancelled)

Source(s):

• jobs.<job_id>.steps.if
• Job status check functions

fast_finish

In Travis, the build won’t be marked as finished until all jobs have completed. There is a feature to mark the build as finished as soon as possible. This is triggered by setting fast_finish to true:

matrix:
  ...
  fast_finish: true

Now, the build result will be determined as soon as all the required jobs finish, while the rest of the allow_failures jobs continue to run.

Github Actions works this differently: as soon as any matrix job fails, all in-progress jobs are cancelled. It doesn't make a distinction between required to pass or allowed to fail.

So by default, GHA has This sort-of the same behaviour as Travis, with the exception that you can not see if any subsequent (cancelled) jobs might have failed, had they run.

To have all jobs in a matrix run, regardless if any job in that matrix fails, use:

jobs:
  some-job:
    strategy:
      matrix:
        fail-fast: false

TRAVIS_BUILD_DIR

Use ${{ github.workspace }}, for example:

env:
  TRAVIS_BUILD_DIR: ${{ github.workspace }}

Or the GITHUB_WORKSPACE environment variable.

The workspace directory is a copy of the repository if the workflow uses the actions/checkout action, otherwise the directory will be empty.

TRAVIS_COMMIT

Use ${{ github.sha }}, for example:

env:
  TRAVIS_COMMIT: ${{ github.sha }}

Or the GITHUB_SHA environment variable