| 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 workflows. 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 the specific guide:
- Building and testing Node.js
- Building and testing Python
- Building and testing PowerShell
- Building and testing Java with Maven
- Building and testing Java with Gradle
- Building and testing Java with Ant
{% 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: 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-latest
steps:
- 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: python
python:
- "3.7"
script:
- python script.py{% endraw %}
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.pyTravis CI and {% data variables.product.prodname_actions %} let you manually cache dependencies for later reuse.
{% ifversion actions-caching %}
These examples demonstrate the cache syntax for each system.
{% raw %}
language: node_js
cache: npm{% endraw %}
- 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-{% else %}
{% data reusables.actions.caching-availability %}
{% endif %}
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 install
script:
- npm run build
- npm test{% endraw %}
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 testTo continue learning about the main features of {% data variables.product.prodname_actions %}, see "AUTOTITLE."