このバージョンの GitHub Enterprise はこの日付をもって終了となります: 2021-09-23. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてください。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してください。

GitLab CI/CD から GitHub Actions への移行

GitHub Actions と GitLab CI/CDはいくつかの点で設定が似ているため、GitHub Actions への移行は比較的簡単です。

ノート: GitHub Actionsは、GitHub Enterprise Server 2.22で限定ベータとして利用可能でした。 ベータは終了しました。 GitHub Actionsは、GitHub Enterprise Server 3.0以降で一般に利用可能になりました。 詳しい情報については、GitHub Enterprise Server 3.0 のリリースノートを参照してください。


ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情報を見ることができます。

はじめに

GitLab CI/CD と GitHub Actions は、どちらも自動的にコードのビルド、テスト、公開、リリース、デプロイを行うワークフローを作成できます。 GitLab CI/CD と GitHub Actions は、ワークフローの設定において似ているところがあります。

  • ワークフローの設定ファイルはYAMLで書かれ、コードのリポジトリに保存されます。
  • ワークフローには1つ以上のジョブが含まれます。
  • ジョブには1つ以上のステップもしくは個別のコマンドが含まれます。
  • ジョブは、マネージドマシンまたはセルフホストマシンのいずれかで実行できます。

いくつかの違いがありますので、このガイドでは、ワークフローを GitHub Actions に移行できるようにする際の重要な違いを説明します。

ジョブ

GitLab CI/CD のジョブは、GitHub Actions のジョブと非常によく似ています。 どちらのシステムでも、ジョブは以下の特徴を持ちます。

  • ジョブには、順番に実行される一連のステップまたはスクリプトが含まれています。
  • ジョブは、個別のマシンまたは個別のコンテナで実行できます。
  • ジョブは、デフォルトでは並列に実行されますが、順次実行するように設定することもできます。

ジョブ内でスクリプトまたはシェルコマンドを実行できます。 GitLab CI/CD では、script キーを使用してスクリプトステップを指定します。 GitHub Actionsでは、すべてのスクリプトはrunキーを使って指定されます。

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

GitLab CI/CD GitHub Actions
job1:
  variables:
    GIT_CHECKOUT: "true"
  script:
    - echo "Run your script here"
jobs:
  job1:
    steps:
      - uses: actions/checkout@v2
      - run: echo "Run your script here"

ランナー

ランナーは、ジョブが実行されるマシンです。 GitLab CI/CD と GitHub Actions はどちらも、マネージドおよびセルフホストのランナーのバリエーションを提供しています。 GitLab CI/CD では、さまざまなプラットフォームでジョブを実行するために tags を使用しますが、GitHub Actions では runs-on を使用します。

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

GitLab CI/CD GitHub Actions
windows_job:
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

linux_job:
  tags:
    - linux
  script:
    - echo "Hello, $USER!"
windows_job:
  runs-on : windows-latest
  steps:
    - run: echo Hello, %USERNAME%!

linux_job:
  runs-on: ubuntu-latest
  steps:
    - run: echo "Hello, $USER!"

詳しい情報については、「GitHub Actions のワークフロー構文」を参照してください。

Docker イメージ

GitLab CI/CD と GitHub Actions はどちらも、Docker イメージ内でのジョブの実行をサポートしています。 GitLab CI/CD では、Docker イメージは image キーで定義しますが、GitHub Actions では container キーで定義します。

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

GitLab CI/CD GitHub Actions
my_job:
  image: node:10.16-jessie
jobs:
  my_job:
    container: node:10.16-jessie

詳しい情報については、「GitHub Actions のワークフロー構文」を参照してください。

条件と式の構文

GitLab CI/CD は、特定の条件でジョブを実行するかどうかを決定するために rules を使用します。 GitHub Actions は、if キーワードを使用して、条件が満たされない限りジョブが実行されないようにします。

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

GitLab CI/CD GitHub Actions
deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"'
jobs:
  deploy_prod:
    if: contains( github.ref, 'master')
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to production server"

詳しい情報については、「GitHub Actions のコンテキストと式構文」を参照してください。

ジョブ間の依存関係

GitLab CI/CD と GitHub Actions の両方で、ジョブの依存関係を設定できます。 どちらのシステムでも、ジョブはデフォルトで並行して実行されますが、GitHub Actions のジョブの依存関係は needs キーで明示的に指定できます。 GitLab CI/CD には、stages の概念もあります。ステージ内のジョブは同時に実行されますが、次のステージは、前のステージのすべてのジョブが完了すると開始されます。 このシナリオは、needs キーを使用して GitHub Actions で再作成できます。

以下は、それぞれのシステムにおける構文の例です。 ワークフローは、build_abuild_b という名前の 2 つのジョブを並行して実行することから始まり、これらのジョブが完了すると、test_ab という別のジョブが実行されます。 最後に、test_ab が完了すると、deploy_ab ジョブが実行されます。

GitLab CI/CD GitHub Actions
stages:
  - build
  - test
  - deploy

build_a:
  stage: build
  script:
    - echo "This job will run first."

build_b:
  stage: build
  script:
    - echo "This job will run first, in parallel with build_a."

test_ab:
  stage: test
  script:
    - echo "This job will run after build_a and build_b have finished."

deploy_ab:
  stage: deploy
  script:
    - echo "This job will run after test_ab is complete"
jobs:
  build_a:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first."

  build_b:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first, in parallel with build_a"

  test_ab:
    runs-on: ubuntu-latest
    needs: [build_a,build_b]
    steps:
      - run: echo "This job will run after build_a and build_b have finished"

  deploy_ab:
    runs-on: ubuntu-latest
    needs: [test_ab]
    steps:
      - run: echo "This job will run after test_ab is complete"

詳細については、「GitHub Actionsのワークフロー構文」を参照してください。

ワークフローのスケジューリング

GitLab CI/CD と GitHub Actions の両方を使用すると、特定の間隔でワークフローを実行できます。 GitLab CI/CD では、パイプラインスケジュールは UI で設定されますが、GitHub Actions では、「on」キーを使用してスケジュールされた間隔でワークフローをトリガーできます。

詳しい情報については、「ワークフローをトリガーするイベント」を参照してください。

変数とシークレット

GitLab CI/CD および GitHub Actions は、パイプラインまたはワークフロー設定ファイルでの環境変数の設定、および GitLab または GitHub Enterprise Server UI を使用したシークレットの作成をサポートしています。

詳しい情報については、「環境変数」および「暗号化されたシークレット」を参照してください。

キャッシング

GitLab CI/CD と GitHub Actions では、設定ファイルにワークフローファイルを手動でキャッシュするためのメソッドがあります。

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

GitLab CI/CD GitHub Actions
image: node:latest

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .npm/

before_script:
  - npm ci --cache .npm --prefer-offline

test_async:
  script:
    - node ./specs/start.js ./specs/async.spec.js
jobs:
  test_async:
    - name: Cache node modules
      uses: actions/cache@v2
      with:
        path: ~/.npm
        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
        restore-keys: v1-npm-deps-

GitHub Actions キャッシングは、GitHub ホストランナーにのみ適用できます。 詳しい情報については、「ワークフローを高速化するための依存関係のキャッシュ」を参照してください。

成果物

GitLab CI/CD と GitHub Actions はどちらも、ジョブによって作成されたファイルとディレクトリを成果物としてアップロードできます。 GitHub Actions では、成果物を使用して、複数のジョブ間でデータを永続化できます。

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

GitLab CI/CD GitHub Actions
script:
artifacts:
  paths:
    - math-homework.txt
- name: Upload math result for job 1
  uses: actions/upload-artifact@v2
  with:
    name: homework
    path: math-homework.txt

詳しい情報については、「ワークフローデータを成果物として保存する」を参照してください。

データベースとサービスコンテナ

どちらのシステムでも、データベース、キャッシング、あるいはその他の依存関係のための追加コンテナを含めることができます。

GitLab CI/CD では、ジョブのコンテナは image キーで指定しますが、GitHub Actions は container キーを使用します。 どちらのシステムでも、追加のサービスコンテナは services キーで指定します。

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

GitLab CI/CD GitHub Actions
container-job:
  variables:
    POSTGRES_PASSWORD: postgres
    # PostgreSQLサービスコンテナと通信するために
    # 使われるホスト名
    POSTGRES_HOST: postgres
    # PostgreSQLのデフォルトのポート
    POSTGRES_PORT: 5432
  image: node:10.18-jessie
  services:
    - postgres
  script:
    # `package.json`ファイル中のすべての依存関係を
    # クリーンインストールする
    - npm ci
    # PostgreSQLクライアントを作成し、クライアントにデータを
    # 展開し、データを取り出すスクリプトを実行する
    - node client.js
  tags:
    - docker
jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie

    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres

    steps:
      - name: Check out repository code
        uses: actions/checkout@v2

      # 「package.json」ファイル内のすべての依存関係の 
      # クリーンインストールを実行する
      - name: Install dependencies
        run: npm ci

      - name: Connect to PostgreSQL
        # PostgreSQL クライアントを作成してクライアントにデータを入力し 
        # データを取得するスクリプトを実行する
        run: node client.js
        env:
          # PostgreSQL サービスコンテナとの通信に
          # 使用されるホスト名
          POSTGRES_HOST: postgres
          # デフォルトの PostgreSQL ポート
          POSTGRES_PORT: 5432

詳しい情報については、「サービスコンテナについて」を参照してください。

このドキュメントは役立ちましたか?プライバシーポリシー

これらのドキュメントを素晴らしいものにするのを手伝ってください!

GitHubのすべてのドキュメントはオープンソースです。間違っていたり、はっきりしないところがありましたか?Pull Requestをお送りください。

コントリビューションを行う

OR, コントリビューションの方法を学んでください。

問題がまだ解決していませんか?

GitHubコミュニティで質問するサポートへの連絡