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

はじめに

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 キーを使ってすべてのスクリプトを指定します。

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

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 を使います。

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

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 では、image キーを使って Docker イメージを定義しますが、GitHub Actions では container キーで行います。

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

my_job: image: node:10.16-jessie 

jobs: my_job: container: node:10.16-jessie 

詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

条件と式の構文

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

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

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" 

詳細については、「式」を参照してく� さい。

ジョブ間の依存関係

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

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

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 では、設定ファイルにワークフローファイルを手動でキャッシュするためのメソッドがあります。

GitHub Actions キャッシュは、GitHub.com または GitHub Enterprise Server 3.5 以降でホストされているリポジトリでのみ使用できます。 詳細については、「ワークフローを高速化するための依存関係のキャッシュ」を参照してく� さい。

Artifacts

GitLab CI/CD と GitHub Actions はどちらも、ジョブによって作成されたファイルとディレクトリを成果物としてアップロードできます。 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 キーで指定します。

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

container-job: variables: POSTGRES_PASSWORD: postgres # The hostname used to communicate with the # PostgreSQL service container POSTGRES_HOST: postgres # The default PostgreSQL port POSTGRES_PORT: 5432 image: node:10.18-jessie services: - postgres script: # Performs a clean installation of all dependencies # in the `package.json` file - npm ci # Runs a script that creates a PostgreSQL client, # populates the client with data, and retrieves data - 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 # Performs a clean installation of all dependencies # in the `package.json` file - name: Install dependencies run: npm ci - name: Connect to PostgreSQL # Runs a script that creates a PostgreSQL client, # populates the client with data, and retrieves data run: node client.js env: # The hostname used to communicate with the # PostgreSQL service container POSTGRES_HOST: postgres # The default PostgreSQL port POSTGRES_PORT: 5432 

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