ノート: 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 |
---|---|
|
|
ランナー
ランナーは、ジョブが実行されるマシンです。 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 イメージ内でのジョブの実行をサポートしています。 In GitLab CI/CD, Docker images are defined with an image
key, while in GitHub Actions it is done with the container
key.
以下が、それぞれのシステ� の構文の例です。
GitLab CI/CD | GitHub Actions |
---|---|
|
|
詳しい情� �については、「GitHub Actions のワークフロー構文」を参照してく� さい。
条件と式の構文
GitLab CI/CD は、特定の条件でジョブを実行するかどうかを決定するために rules
を使用します。 GitHub Actions は、if
キーワードを使用して、条件が満たされない限りジョブが実行されないようにします。
以下が、それぞれのシステ� の構文の例です。
GitLab CI/CD | GitHub Actions |
---|---|
|
|
For more information, see "Expressions."
ジョブ間の依存関係
GitLab CI/CD と GitHub Actions の両方で、ジョブの依存関係を設定できます。 どちらのシステ� でも、ジョブはデフォルトで並行して実行されますが、GitHub Actions のジョブの依存関係は needs
キーで明示的に指定できます。 GitLab CI/CD には、stages
の概念もあります。ステージ内のジョブは同時に実行されますが、次のステージは、前のステージのすべてのジョブが完了すると開始されます。 このシナリオは、needs
キーを使用して GitHub Actions で再作成できます。
以下は、それぞれのシステ� における構文の例です。 ワークフローは、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 caching is only available for repositories hosted on GitHub.com or GitHub Enterprise Server 3.5 and later. 詳しい情� �については、「ワークフローを高速化するための依存関係のキャッシュ」を参照してく� さい。
成果物
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 |
---|---|
|
|
詳しい情� �については、「サービスコンテナについて」を参照してく� さい。