注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。
はじめに
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 |
---|---|
|
|
ランナー
ランナーは、ジョブが実行されるマシンです。 GitLab CI/CD と GitHub Actions はどちらも、マネージドおよびセルフホストのランナーのバリエーションを提供しています。 GitLab CI/CD では、異なるプラットフォー� でジョブを実行するために tags
を使いますが、GitHub Actions では runs-on
を使います。
以下が、それぞれのシステ� の構文の例です。
GitLab CI/CD | GitHub Actions |
---|---|
|
|
詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。
Docker イメージ
GitLab CI/CD と GitHub Actions はどちらも、Docker イメージ内でのジョブの実行をサポートしています。 GitLab CI/CD では、image
キーを使って Docker イメージを定義しますが、GitHub Actions では container
キーで行います。
以下が、それぞれのシステ� の構文の例です。
GitLab CI/CD | GitHub Actions |
---|---|
|
|
詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。
条件と式の構文
GitLab CI/CD では、特定の条件でジョブを実行するかどうかを決定するために rules
を使います。 GitHub Actions では、条件が満たされない� �合にジョブが実行されないようにするには、if
キーワードを使います。
以下が、それぞれのシステ� の構文の例です。
GitLab CI/CD | GitHub Actions |
---|---|
|
|
詳細については、「式」を参照してく� さい。
ジョブ間の依存関係
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 | GitHub Actions |
---|---|
|
|
詳細については、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 では、成果物を使用して、複数のジョブ間でデータを永続化できます。
以下が、それぞれのシステ� の構文の例です。
GitLab CI/CD | GitHub Actions |
---|---|
|
|
詳しくは、「ワークフロー データを成果物として保存する」をご覧く� さい。
データベースとサービスコンテナ
どちらのシステ� でも、データベース、キャッシング、あるいはその他の依存関係のための追� コンテナを含めることができます。
GitLab CI/CD ではジョブのコンテナーを image
キーで指定しますが、GitHub Actions では container
キーを使います。 どちらのシステ� でも、追� のサービス コンテナーは services
キーで指定します。
以下が、それぞれのシステ� の構文の例です。
GitLab CI/CD | GitHub Actions |
---|---|
|
|
詳細については、「サービス コンテナーについて」を参照してく� さい。