| 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 %}. |
|
| tutorial |
| Migrate from Travis CI |
{% data reusables.actions.enterprise-github-hosted-runners %}
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 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.
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.
{% data variables.product.prodname_actions %} and Travis CI share certain similarities, and understanding these ahead of time can help smooth the migration process.
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.
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.
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.
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.
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.
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.
{% raw %}
matrix: include: - rvm: '2.5' - rvm: '2.6.3'{% endraw %}
{% raw %}
jobs: build: strategy: matrix: ruby: ['2.5', '2.6.3']{% endraw %}
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.
{% raw %}
branches: only: - main - 'mona/octocat'{% endraw %}
{% raw %}
on: push: branches: - main - 'mona/octocat'{% endraw %}
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.
{% raw %}
git: submodules: false{% endraw %}
- uses: {% data reusables.actions.action-checkout %}with: submodules: falseTravis 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 %}
When migrating from Travis CI, consider the following key features in {% data variables.product.prodname_actions %}:
{% 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.
{% 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.
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 %}
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 %}
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.
{% 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 scriptrun: ./.github/scripts/build.shshell: bashWhen migrating to {% data variables.product.prodname_actions %}, there are different approaches to error handling that you might need to be aware of.
{% data variables.product.prodname_actions %} stops a job immediately if one of the steps returns an error code. For more information, see AUTOTITLE.
{% 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.
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-lateststeps: - run: echo "This step runs with str equals 'ABC' and num equals 123"if: env.str == 'ABC' && env.num == 123Where 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.
{% raw %}
language: pythonpython: - "3.7"script: - python script.py{% endraw %}
jobs: run_python: runs-on: ubuntu-lateststeps: - uses: {% data reusables.actions.action-setup-python %}with: python-version: '3.7'architecture: 'x64' - run: python script.pyTravis CI and {% data variables.product.prodname_actions %} let you manually cache dependencies for later reuse.
These examples demonstrate the cache syntax for each system.
{% raw %}
language: node_jscache: npm{% endraw %}
- name: Cache node modulesuses: {% data reusables.actions.action-cache %}with: path: ~/.npmkey: {% raw %}v1-npm-deps-${{ hashFiles('**/package-lock.json') }}{% endraw %}restore-keys: v1-npm-deps-This section compares how {% data variables.product.prodname_actions %} and Travis CI perform common tasks.
You can create custom environment variables in a {% data variables.product.prodname_actions %} job.
env: - MAVEN_PATH="/usr/local/maven"jobs: maven-build: env: MAVEN_PATH: '/usr/local/maven'{% raw %}
install: - npm installscript: - npm run build - npm test{% endraw %}
name: Node.js CIon: [push]jobs: build: runs-on: ubuntu-lateststeps: - uses: {% data reusables.actions.action-checkout %} - name: Use Node.jsuses: {% data reusables.actions.action-setup-node %}with: node-version: '16.x' - run: npm install - run: npm run build - run: npm testTo continue learning about the main features of {% data variables.product.prodname_actions %}, see AUTOTITLE.
