ノート: GitHub Actionsは、GitHub Enterprise Server 2.22で限定ベータとして利用可能でした。 ベータは終了しました。 GitHub Actionsは、GitHub Enterprise Server 3.0以降で一般に利用可能になりました。 詳しい情報については、GitHub Enterprise Server 3.0 のリリースノートを参照してください。
- GitHub Enterprise Server 3.0以降へのアップグレードに関する詳しい情報については「GitHub Enterprise Serverのアップグレード」を参照してください。
- アップグレード後のGitHub Actionsの設定に関する詳しい情報については、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 |
---|---|
|
|
ランナー
ランナーは、ジョブが実行されるマシンです。 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 では、設定ファイルにワークフローファイルを手動でキャッシュするためのメソッドがあります。
以下が、それぞれのシステムの構文の例です。
GitLab CI/CD | GitHub Actions |
---|---|
|
|
GitHub Actions キャッシングは、GitHub ホストランナーにのみ適用できます。 詳しい情報については、「ワークフローを高速化するための依存関係のキャッシュ」を参照してください。
成果物
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 |
---|---|
|
|
詳しい情報については、「サービスコンテナについて」を参照してください。