docs/content/actions/tutorials/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md

title, intro, redirect_from, versions, type, topics, shortTitle

title	intro	redirect_from	versions	type	topics	shortTitle
Migrating from Travis CI to GitHub Actions	{% data variables.product.prodname_actions %} and Travis CI share multiple similarities, which helps make it relatively straightforward to migrate to {% data variables.product.prodname_actions %}.	/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions /actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions /actions/migrating-to-github-actions/manual-migrations/migrating-from-travis-ci-to-github-actions /actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-travis-ci-to-github-actions /actions/how-tos/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-travis-ci-to-github-actions	fpt ghes ghec * * *	tutorial	Travis CI Migration CI CD	Migrate from Travis CI

{% data reusables.actions.enterprise-github-hosted-runners %}

Introduction

This guide helps you migrate from Travis CI to {% data variables.product.prodname_actions %}. It compares their concepts and syntax, describes the similarities, and demonstrates their different approaches to common tasks.

Before you start

Before starting your migration to {% data variables.product.prodname_actions %}, it would be useful to become familiar with how it works:

• For a quick example that demonstrates a {% data variables.product.prodname_actions %} job, see AUTOTITLE.
• To learn the essential {% data variables.product.prodname_actions %} concepts, see AUTOTITLE.

Comparing job execution

To give you control over when CI tasks are executed, a {% data variables.product.prodname_actions %} workflow uses jobs that run in parallel by default. Each job contains steps that are executed in a sequence that you define. If you need to run setup and cleanup actions for a job, you can define steps in each job to perform these.

Key similarities

{% data variables.product.prodname_actions %} and Travis CI share certain similarities, and understanding these ahead of time can help smooth the migration process.

Using YAML syntax

Travis CI and {% data variables.product.prodname_actions %} both use YAML to create jobs and workflows, and these files are stored in the code's repository. For more information on how {% data variables.product.prodname_actions %} uses YAML, see AUTOTITLE.

Custom variables

Travis CI lets you set variables and share them between stages. Similarly, {% data variables.product.prodname_actions %} lets you define variables for a workflow. For more information, see AUTOTITLE.

Default variables

Travis CI and {% data variables.product.prodname_actions %} both include default environment variables that you can use in your YAML files. For {% data variables.product.prodname_actions %}, you can see these listed in AUTOTITLE.

Parallel job processing

Travis CI can use stages to run jobs in parallel. Similarly, {% data variables.product.prodname_actions %} runs jobs in parallel. For more information, see AUTOTITLE.

Status badges

Travis CI and {% data variables.product.prodname_actions %} both support status badges, which let you indicate whether a build is passing or failing. For more information, see AUTOTITLE.

Using a matrix

Travis CI and {% data variables.product.prodname_actions %} both support a matrix, allowing you to perform testing using combinations of operating systems and software packages. For more information, see AUTOTITLE.

Below is an example comparing the syntax for each system.

Travis CI syntax for a matrix

{% raw %}

matrix:
  include:
    - rvm: '2.5'
    - rvm: '2.6.3'

{% endraw %}

{% data variables.product.prodname_actions %} syntax for a matrix

{% raw %}

jobs:
  build:
    strategy:
      matrix:
        ruby: ['2.5', '2.6.3']

{% endraw %}

Targeting specific branches

Travis CI and {% data variables.product.prodname_actions %} both allow you to target your CI to a specific branch. For more information, see AUTOTITLE.

Below is an example of the syntax for each system.

Travis CI syntax for targeting specific branches

{% raw %}

branches:
  only:
    - main
    - 'mona/octocat'

{% endraw %}

{% data variables.product.prodname_actions %} syntax for targeting specific branches

{% raw %}

on:
  push:
    branches:
      - main
      - 'mona/octocat'

{% endraw %}

Checking out submodules

Travis CI and {% data variables.product.prodname_actions %} both allow you to control whether submodules are included in the repository clone.

Below is an example of the syntax for each system.

Travis CI syntax for checking out submodules

{% raw %}

git:
  submodules: false

{% endraw %}

{% data variables.product.prodname_actions %} syntax for checking out submodules

- uses: {% data reusables.actions.action-checkout %}
  with:
    submodules: false

Using environment variables in a matrix

Travis CI and {% data variables.product.prodname_actions %} can both add custom variables to a test matrix, which allows you to refer to the variable in a later step.

In {% data variables.product.prodname_actions %}, you can use the include key to add custom environment variables to a matrix. {% data reusables.actions.matrix-variable-example %}

Key features in {% data variables.product.prodname_actions %}

When migrating from Travis CI, consider the following key features in {% data variables.product.prodname_actions %}:

Storing secrets

{% data variables.product.prodname_actions %} allows you to store secrets and reference them in your jobs. {% data variables.product.prodname_actions %} organizations can limit which repositories can access organization secrets. Deployment protection rules can require manual approval for a workflow to access environment secrets. For more information, see AUTOTITLE.

Sharing files between jobs and workflows

{% data variables.product.prodname_actions %} includes integrated support for artifact storage, allowing you to share files between jobs in a workflow. You can also save the resulting files and share them with other workflows. For more information, see AUTOTITLE.

Hosting your own runners

If your jobs require specific hardware or software, {% data variables.product.prodname_actions %} allows you to host your own runners and send your jobs to them for processing. {% data variables.product.prodname_actions %} also lets you use policies to control how these runners are accessed, granting access at the organization or repository level. For more information, see AUTOTITLE.

{% ifversion fpt or ghec %}

Concurrent jobs and execution time

The concurrent jobs and workflow execution times in {% data variables.product.prodname_actions %} can vary depending on your {% data variables.product.company_short %} plan. For more information, see AUTOTITLE.

{% endif %}

Using different languages in {% data variables.product.prodname_actions %}

When working with different languages in {% data variables.product.prodname_actions %}, you can create a step in your job to set up your language dependencies. For more information about working with a particular language, see AUTOTITLE.

Executing scripts

{% data variables.product.prodname_actions %} can use run steps to run scripts or shell commands. To use a particular shell, you can specify the shell type when providing the path to the script. For more information, see AUTOTITLE.

For example:

steps:
  - name: Run build script
    run: ./.github/scripts/build.sh
    shell: bash

Error handling in {% data variables.product.prodname_actions %}

When migrating to {% data variables.product.prodname_actions %}, there are different approaches to error handling that you might need to be aware of.

Script error handling

{% data variables.product.prodname_actions %} stops a job immediately if one of the steps returns an error code. For more information, see AUTOTITLE.

Job error handling

{% data variables.product.prodname_actions %} uses if conditionals to execute jobs or steps in certain situations. For example, you can run a step when another step results in a failure(). For more information, see AUTOTITLE. You can also use continue-on-error to prevent a workflow run from stopping when a job fails.

Migrating syntax for conditionals and expressions

To run jobs under conditional expressions, Travis CI and {% data variables.product.prodname_actions %} share a similar if condition syntax. {% data variables.product.prodname_actions %} lets you use the if conditional to prevent a job or step from running unless a condition is met. For more information, see AUTOTITLE.

This example demonstrates how an if conditional can control whether a step is executed:

jobs:
  conditional:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This step runs with str equals 'ABC' and num equals 123"
        if: env.str == 'ABC' && env.num == 123

Migrating phases to steps

Where Travis CI uses phases to run steps, {% data variables.product.prodname_actions %} has steps which execute actions. You can find prebuilt actions in the {% data variables.product.prodname_marketplace %}, or you can create your own actions. For more information, see AUTOTITLE.

Below is an example of the syntax for each system.

Travis CI syntax for phases and steps

{% raw %}

language: python
python:
  - "3.7"

script:
  - python script.py

{% endraw %}

{% data variables.product.prodname_actions %} syntax for steps and actions

jobs:
  run_python:
    runs-on: ubuntu-latest
    steps:
      - uses: {% data reusables.actions.action-setup-python %}
        with:
          python-version: '3.7'
          architecture: 'x64'
      - run: python script.py

Caching dependencies

Travis CI and {% data variables.product.prodname_actions %} let you manually cache dependencies for later reuse.

These examples demonstrate the cache syntax for each system.

Travis CI syntax for caching

{% raw %}

language: node_js
cache: npm

{% endraw %}

GitHub Actions syntax for caching

- name: Cache node modules
  uses: {% data reusables.actions.action-cache %}
  with:
    path: ~/.npm
    key: {% raw %}v1-npm-deps-${{ hashFiles('**/package-lock.json') }}{% endraw %}
    restore-keys: v1-npm-deps-

Examples of common tasks

This section compares how {% data variables.product.prodname_actions %} and Travis CI perform common tasks.

Configuring environment variables

You can create custom environment variables in a {% data variables.product.prodname_actions %} job.

Travis CI syntax for an environment variable

env:
  - MAVEN_PATH="/usr/local/maven"

{% data variables.product.prodname_actions %} workflow with an environment variable

jobs:
  maven-build:
    env:
      MAVEN_PATH: '/usr/local/maven'

Building with Node.js

Travis CI for building with Node.js

{% raw %}

install:
  - npm install
script:
  - npm run build
  - npm test

{% endraw %}

{% data variables.product.prodname_actions %} workflow for building with Node.js

name: Node.js CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: {% data reusables.actions.action-checkout %}
      - name: Use Node.js
        uses: {% data reusables.actions.action-setup-node %}
        with:
          node-version: '16.x'
      - run: npm install
      - run: npm run build
      - run: npm test

Next steps

To continue learning about the main features of {% data variables.product.prodname_actions %}, see AUTOTITLE.