Note: GitHub Actions was available for GitHub Enterprise Server 2.22 as a limited beta. The beta has ended. GitHub Actions is now generally available in GitHub Enterprise Server 3.0 or later. For more information, see the GitHub Enterprise Server 3.0 release notes.
- For more information about upgrading to GitHub Enterprise Server 3.0 or later, see "Upgrading GitHub Enterprise Server."
- For more information about configuring GitHub Actions after you upgrade, see the documentation for GitHub Enterprise Server 3.0.
Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.
はじめに
CircleCIとGitHub Actionsは、どちらも自動的にコードのビルド、テスト、公開、リリース、デプロイを行うワークフローを作成できます。 CircleCIとGitHub Actionsは、ワークフローの設定において似ているところがあります。
- ワークフローの設定ファイルはYAMLで書かれ、リポジトリに保存されます。
- ワークフローには1つ以上のジョブが含まれます。
- ジョブには1つ以上のステップもしくは個別のコマンドが含まれます。
- ステップもしくはタスクは、再利用とコミュニティとの共有が可能です。
詳しい情報については、「GitHub Actionsの中核的概念」を参照してください。
主要な差異
CircleCIから移行する際には、以下の差異を考慮してください。
- CircleCIの自動テストの並列性は、ユーザが指定したルールもしくは過去のタイミングの情報に基づいて、自動的にテストをグループ化します。 この機能はGitHub Actionsには組み込まれていません。
- コンテナはユーザのマッピングが異なるので、Dockerコンテナ内で実行されるアクションは、権限の問題に敏感です。 これらの問題の多くは、Dockerfile中で
USER
命令を使わなければ回避できます。 GitHub Enterprise Serverホストランナー上のDockerのファイルシステムに関する詳しい情報については「GitHub Enterprise Serverホストランナーの仮想環境」を参照してください。
ワークフローとジョブの移行
CircleCIはconfig.ymlファイル中でworkflows
を定義するので、複数のワークフローを設定できます。 GitHub Enterprise Serverはワークフローごとに1つのワークフローファイルを必要とするので、結果としてworkflows
を宣言する必要がありません。 それぞれのワークフローごとに、config.ymlで内で設定された新しいワークフローファイルを作成しなければなりません。
CircleCIとGitHub Actionsは、どちらも似た構文を使って設定ファイル中でjobs
を設定します。 CircleCIワークフロー中でrequires
を使ってジョブ間の依存関係を設定しているなら、相当するGitHub Actionsのneeds
構文を利用できます。 詳細については、「GitHub Actionsのワークフロー構文」を参照してください。
orbsからアクションへの移行
CircleCIとGitHub Actionsは、どちらもワークフロー中のタスクを再利用し、共有するための仕組みを提供しています。 CircleCIはorbsという概念を利用します。これはYAMLで書かれ、ワークフロー中で再利用できるタスクを提供します。 GitHub Actionsはアクションと呼ばれる強力で柔軟な再利用できるコンポーネントを持っており、これはJavaScriptファイルもしくはDockerイメージで構築できます。 GitHub Enterprise Serverの API やパブリックに利用可能なサードパーティAPIとのインテグレーションなど、好きな方法でリポジトリを操作するカスタムコードを書いて、アクションを作成することができます。 たとえば、アクションでnpmモジュールを公開する、緊急のIssueが発生したときにSMSアラートを送信する、本番対応のコードをデプロイすることなどが可能です。 詳細については、「アクションを作成する」を参照してください。
CircleCIは、YAMLのアンカーとエイリアスでワークフローの部分を再利用できます。 GitHub Actionsはビルドマトリックスを使って、再利用性についての一般的な要求のほとんどをサポートします。 ビルドマトリックスに関する詳細な情報については「複雑なワークフローを管理する」を参照してください。
Dockerイメージの利用
CircleCIとGitHub Actionsは、どちらもDockerイメージ内でのステップの実行をサポートします。
CircleCIは、共通の依存関係を持つ一連のビルド済みのイメージを提供します。 これらのイメージではUSER
がcircleci
に設定されており、それがGitHub Actionsとの権限の衝突を引き起こすことになります。
GitHub Actionsへの移行に際しては、CircleCIの構築済みイメージから離脱することをおすすめします。 多くの場合、必要な追加の依存関係のインストールにアクションを使うことができます。
Dockerのファイルシステムに関する詳しい情報については「GitHub Enterprise Serverホストランナーの仮想環境」を参照してください。
GitHubホストの仮想環境で利用できるツールとパッケージに関する詳しい情報については「GitHub ホストランナーの仕様」を参照してください。
変数とシークレットの利用
CircleCIとGitHub Actionsは、設定ファイル内での環境変数の設定と、CircleCIもしくはGitHub Enterprise ServerのUIを使ったシークレットの作成をサポートしています。
詳しい情報については「環境変数の利用」及び「暗号化されたシークレットの作成と利用」を参照してください。
キャッシング
CircleCIとGitHub Actionsは、設定ファイル中で手動でファイルをキャッシュする方法を提供しています。
以下は、それぞれのシステムにおける構文の例です。
CircleCI | GitHub Actions |
---|---|
|
|
GitHub Actions キャッシングは、GitHub ホストランナーにのみ適用できます。 詳しい情報については、「ワークフローを高速化するための依存関係のキャッシュ」を参照してください。
GitHub Actionsは、CircleCIのDocker Layer Caching(DLC)に相当する機能を持っていません。
ジョブ間でのデータの永続化
CircleCIとGitHub Actionsは、どちらもジョブ間でデータを永続化するための仕組みを提供しています。
以下は、CircleCIとGitHub Actionsの設定構文の例です。
CircleCI | GitHub Actions |
---|---|
|
|
詳しい情報については「成果物を利用してワークフローのデータを永続化する」を参照してください。
データベースとサービスコンテナの利用
どちらのシステムでも、データベース、キャッシング、あるいはその他の依存関係のための追加コンテナを含めることができます。
CircleCIでは、config.yamlで最初に挙げられているイメージが、コマンドの実行に使われる主要なイメージです。 GitHub Actionsは明示的なセクションを使います。主要なコンテナにはcontainer
を使い、追加のコンテナはservices
にリストしてください。
以下は、CircleCIとGitHub Actionsの設定構文の例です。
CircleCI | GitHub Actions |
---|---|
|
|
詳しい情報については「サービスコンテナについて」を参照してください。
完全な例
以下は実際の例です。 左は thoughtbot/administratorリポジトリのための実際のconfig.ymlを示しています。 右は、同等のGitHub Actionsを示しています。
CircleCI | GitHub Actions |
---|---|
|
|