はじめに
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 構文
job1:
variables:
GIT_CHECKOUT: "true"
script:
- echo "Run your script here"
ジョブの GitHub Actions 構文
jobs:
job1:
steps:
- uses: actions/checkout@v4
- run: echo "Run your script here"
ランナー
ランナーは、ジョブが実行されるマシンです。 GitLab CI/CD と GitHub Actions はどちらも、マネージドおよびセルフホストのランナーのバリエーションを提供しています。 GitLab CI/CD では、異なるプラットフォームでジョブを実行するために tags を使いますが、GitHub Actions では runs-on を使います。
以下は、それぞれのシステムにおける構文の例です。
ランナーの GitLab CI/CD 構文
windows_job:
tags:
- windows
script:
- echo Hello, %USERNAME%!
linux_job:
tags:
- linux
script:
- echo "Hello, $USER!"
ランナーの GitHub Actions 構文
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 キーで行います。
以下は、それぞれのシステムにおける構文の例です。
Docker イメージの GitLab CI/CD 構文
my_job:
image: node:20-bookworm-slim
Docker イメージの GitHub Actions 構文
jobs:
my_job:
container: node:20-bookworm-slim
詳しくは、「GitHub Actions のワークフロー構文」を参照してください。
条件と式の構文
GitLab CI/CD では、特定の条件でジョブを実行するかどうかを決定するために rules を使います。 GitHub Actions では、条件が満たされない場合にジョブが実行されないようにするには、if キーワードを使います。
以下は、それぞれのシステムにおける構文の例です。
条件と式の GitLab CI/CD 構文
deploy_prod:
stage: deploy
script:
- echo "Deploy to production server"
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
条件と式の GitHub Actions 構文
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 ジョブが実行されます。
ジョブ間の依存関係の GitLab CI/CD 構文
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"
ジョブ間の依存関係の GitHub Actions 構文
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 Cloud UI を使用したシークレットの作成をサポートしています。
詳細については、「変数に情報を格納する」および「GitHub Actions でのシークレットの使用」を参照してください。
キャッシュ
GitLab CI/CD と GitHub Actions では、設定ファイルにワークフローファイルを手動でキャッシュするためのメソッドがあります。
以下は、それぞれのシステムにおける構文の例です。
キャッシュの GitLab CI/CD 構文
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
キャッシュの GitHub Actions 構文
jobs:
test_async:
runs-on: ubuntu-latest
steps:
- name: Cache node modules
uses: actions/cache@v3
with:
path: ~/.npm
key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
restore-keys: v1-npm-deps-
Artifacts
GitLab CI/CD と GitHub Actions はどちらも、ジョブによって作成されたファイルとディレクトリを成果物としてアップロードできます。 GitHub Actions では、成果物を使用して、複数のジョブ間でデータを永続化できます。
以下は、それぞれのシステムにおける構文の例です。
成果物の GitLab CI/CD 構文
script:
artifacts:
paths:
- math-homework.txt
成果物の GitHub Actions 構文
- name: Upload math result for job 1
uses: actions/upload-artifact@v4
with:
name: homework
path: math-homework.txt
詳しくは、「ワークフローからのデータの格納と共有」を参照してください。
データベースとサービスコンテナ
どちらのシステムでも、データベース、キャッシング、あるいはその他の依存関係のための追加コンテナを含めることができます。
GitLab CI/CD ではジョブのコンテナーを image キーで指定しますが、GitHub Actions では container キーを使います。 どちらのシステムでも、追加のサービス コンテナーは services キーで指定します。
以下は、それぞれのシステムにおける構文の例です。
データベースとサービス コンテナーの GitLab CI/CD 構文
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:20-bookworm-slim
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
データベースとサービス コンテナーの GitHub Actions 構文
jobs:
container-job:
runs-on: ubuntu-latest
container: node:20-bookworm-slim
services:
postgres:
image: postgres
env:
POSTGRES_PASSWORD: postgres
steps:
- name: Check out repository code
uses: actions/checkout@v4
# 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
詳しくは、「サービスコンテナについて」を参照してください。