ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

Migrating from Travis CI to GitHub Actions

GitHub Actions and Travis CI share multiple similarities, which helps make it relatively straightforward to migrate to GitHub Actions.

ここには以下の内容があります:

はじめに

This guide helps you migrate from Travis CI to GitHub 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 GitHub Actions, it would be useful to become familiar with how it works:

Comparing job execution

To give you control over when CI tasks are executed, a GitHub 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

GitHub 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 GitHub Actions both use YAML to create jobs and workflows, and these files are stored in the code's repository. For more information on how GitHub Actions uses YAML, see "Creating a workflow file."

Custom environment variables

Travis CI lets you set environment variables and share them between stages. Similarly, GitHub Actions lets you define environment variables for a step, job, or workflow. For more information, see "Environment variables."

デフォルトの環境変数

Travis CI and GitHub Actions both include default environment variables that you can use in your YAML files. For GitHub Actions, you can see these listed in "Default environment variables."

並列なジョブの処理

Travis CI can use stages to run jobs in parallel. Similarly, GitHub Actions runs jobs in parallel. For more information, see "Creating dependent jobs."

Status badges

Travis CI and GitHub Actions both support status badges, which let you indicate whether a build is passing or failing. For more information, see "Adding a workflow status badge to your repository."

ビルドマトリックスを使用する

Travis CI and GitHub Actions both support a build matrix, allowing you to perform testing using combinations of operating systems and software packages. For more information, see "Using a build matrix."

Below is an example comparing the syntax for each system:

Travis CI GitHub Actions
matrix:
  include:
  - rvm: 2.5
  - rvm: 2.6.3
jobs:
  build:
    strategy:
      matrix:
        ruby: [2.5, 2.6.3]

Targeting specific branches

Travis CI and GitHub Actions both allow you to target your CI to a specific branch. 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

以下が、それぞれのシステムの構文の例です。

Travis CI GitHub Actions
branches:
  only:
  - main
  - 'mona/octocat'
on:
  push:
    branches:    
      - main
      - 'mona/octocat'

Checking out submodules

Travis CI and GitHub Actions both allow you to control whether submodules are included in the repository clone.

以下が、それぞれのシステムの構文の例です。

Travis CI GitHub Actions
git:
  submodules: false
    - uses: actions/checkout@v2
      with:
        submodules: false

Key features in GitHub Actions

When migrating from Travis CI, consider the following key features in GitHub Actions:

シークレットを保存する

GitHub Actions allows you to store secrets and reference them in your jobs. GitHub Actions also includes policies that allow you to limit access to secrets at the repository and organization level. For more information, see "Encrypted secrets."

Sharing files between jobs and workflows

GitHub 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 "Sharing data between jobs."

自分のランナーをホストする

If your jobs require specific hardware or software, GitHub Actions allows you to host your own runners and send your jobs to them for processing. GitHub 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 "Hosting your own runners."

Concurrent jobs and execution time

The concurrent jobs and workflow execution times in GitHub Actions can vary depending on your GitHub plan. 詳しい情報については、「使用制限、支払い、および管理」を参照してください。

Using different languages in GitHub Actions

When working with different languages in GitHub 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:

Executing scripts

GitHub 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. 詳細については、「GitHub Actionsのワークフロー構文」を参照してください。

例:

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

Error handling in GitHub Actions

When migrating to GitHub Actions, there are different approaches to error handling that you might need to be aware of.

Script error handling

GitHub Actions stops a job immediately if one of the steps returns an error code. 詳細については、「GitHub Actionsのワークフロー構文」を参照してください。

Job error handling

GitHub 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(). 詳しい情報については、「GitHub Actions のワークフロー構文」を参照してください。 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 GitHub Actions share a similar if condition syntax. GitHub Actions lets you use the if conditional to prevent a job or step from running unless a condition is met. 詳しい情報については、「GitHub Actions のコンテキストと式構文」を参照してください。

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, GitHub Actions has steps which execute actions. You can find prebuilt actions in the GitHub Marketplace, or you can create your own actions. 詳細については、「アクションの構築について」を参照してください。

以下が、それぞれのシステムの構文の例です。

Travis CI GitHub Actions
language: python
python:
  - "3.7"

script:
  - python script.py
jobs:
  run_python:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/setup-python@v2
      with:
        python-version: '3.7'
        architecture: 'x64'
    - run: python script.py

依存関係のキャッシング

Travis CI and GitHub Actions let you manually cache dependencies for later reuse. This example demonstrates the cache syntax for each system.

Travis CI GitHub Actions
language: node_js
cache: npm
- name: Cache node modules
  uses: actions/cache@v2
  with:
    path: ~/.npm
    key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
    restore-keys: v1-npm-deps-

詳しい情報については、「ワークフローを高速化するための依存関係のキャッシュ」を参照してください。

一般的なタスクの例

This section compares how GitHub Actions and Travis CI perform common tasks.

Configuring environment variables

You can create custom environment variables in a GitHub Actions job. 例:

Travis CI GitHub Actionsのワークフロー
env:
- MAVEN_PATH="/usr/local/maven"
jobs:
  maven-build:
    env:
      MAVEN_PATH: '/usr/local/maven'

Building with Node.js

Travis CI GitHub Actionsのワークフロー
install:
  - npm install
script:
  - npm run build
  - npm test
name: Node.js CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js
      uses: actions/setup-node@v1
      with:
        node-version: '12.x'
    - run: npm install
    - run: npm run build
    - run: npm test

次のステップ

To continue learning about the main features of GitHub Actions, see "Learn GitHub Actions."

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.