GitHub Actions を理解する

概要

GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。 リポジトリに対するすべての pull request をビルドしてテストしたり、マージされた pull request を運用環境にデプロイしたりするワークフローを作成できます。

GitHub Actions は、DevOps であるだけでなく、リポジトリで他のイベントが発生したときにワークフローを実行できます。 たとえば、リポジトリで新しい issue が作成されるたびに、適切なラベルを自動的に追加するワークフローを実行できます。

お使いの GitHub Enterprise Server インスタンス のワークフローを実行するには、独自の Linux、Windows、または macOS 仮想マシンをホストする必要があります。 セルフホステッド ランナーは、物理または仮想にでき、コンテナー内、オンプレミス、またはクラウドに配置できます。

ご自分の企業への GitHub Actions の導入について詳しくは、「企業への GitHub Actions の導入」をご覧ください。

GitHub Actions のコンポーネント

リポジトリで、pull request のオープンや issue の作成などの イベント が発生したときにトリガーされるように GitHub Actions ワークフロー を構成できます。 ワークフローには、1 つ以上の ジョブ が含まれており、ジョブは順次にまたは並列で実行できます。 各ジョブは、専用の仮想マシン ランナー 内、またはコンテナー内で実行され、定義した スクリプト を実行するか、または アクション (ワークフローを簡略化できる再利用可能な拡張機能) を実行する 1 つ以上のステップで構成されます。

Workflows

ワークフローとは、1 つ以上のジョブを実行する構成可能な自動化プロセスです。 ワークフローは、リポジトリにチェックインされる YAML ファイルによって定義され、リポジトリ内のイベントによってトリガーされたときに実行されます。また、手動でトリガーしたり、定義されたスケジュールでトリガーしたりすることもできます。

ワークフローは、リポジトリ内の .github/workflows ディレクトリで定義されます。 1 つのリポジトリに複数のワークフローを含めることができ、各ワークフローでは、次のような異なるタスクを実行できます。

• pull request のビルドとテスト。
• リリースが作成される度にアプリケーションをデプロイ。
• 新しい問題が開かれる度にラベルを追加。

別のワークフロー内のワークフローを参照できます。 詳しくは、「ワークフローの再利用」を参照してください。

詳しくは、「ワークフローの書き込み」を参照してください。

イベント

イベントとは、ワークフロー実行をトリガーする、リポジトリ内の特定のアクティビティです。 たとえば、pull request が作成されたとき、issue が開かれたとき、またはリポジトリにコミットがプッシュされたときに、GitHub からアクティビティを発生させることができます。 また、[スケジュール] に従って、[REST API に投稿] または手動で、ワークフロー実行を作動させることもできます。

ワークフローのトリガーに使用できるイベントの完全な一覧については、「ワークフローをトリガーするイベント」を参照してください。

ジョブ

ジョブとは、同じランナーで実行される、ワークフロー内の一連のステップです。 各ステップは、実行されるシェル スクリプト、または実行される アクション のいずれかです。 ステップは順番に実行され、相互に依存します。 各ステップは同じランナーで実行されるため、あるステップから別のステップにデータを共有できます。 たとえば、アプリケーションをビルドするステップの後に、ビルドされたアプリケーションをテストするステップを続けることができます。

ジョブと他のジョブとの依存関係を構成できます。既定では、ジョブに依存関係はなく、並列で実行されます。 ジョブが別のジョブに依存している場合、そのジョブは、依存しているジョブが完了するまで待機してから実行されます。

たとえば、ジョブに依存していないさまざまなアーキテクチャ用の複数のビルド ジョブと、それらのビルドに依存するパッケージ化ジョブを設定するとします。 ビルド ジョブは並列で実行され、それらがすべて正常に完了したら、パッケージ化ジョブが実行されます。

詳しくは、「ワークフロー動作の選択」を参照してください。

アクション

アクション は、GitHub Actions 用のカスタム アプリケーションであり、複雑で頻繁に繰り返されるタスクを実行します。 アクションを使用すると、ワークフロー ファイルに記述する繰り返しコードの量を削減するのに役立ちます。 アクションでは、GitHub からの Git リポジトリのプル、ビルド環境に適したツールチェーンの設定、またはクラウド プロバイダーに対する認証の設定を実行できます。

独自のアクションを記述することも、GitHub Marketplace で、ワークフローで使用するアクションを見つけることもできます。

アクションを公開せずにエンタープライズ全体でアクションを共有するには、内部リポジトリにアクションを格納し、同じ組織またはエンタープライズ内の任意の組織が所有する他のリポジトリ内の GitHub Actions ワークフローへのアクセスを許可するようにリポジトリを構成します。 詳しくは、「アクションとワークフローを企業と共有する」を参照してください。

アクションの詳細については、「自動化の共有」を参照してください。

ランナー

ランナーとは、ワークフローがトリガーされると実行されるサーバーです。 各ランナーは一度に 1 つのジョブを実行できます。 GitHub Enterprise Serverの独自のランナーをホストする必要があります。

詳細については、「自分のランナーをホストする」を参照してください。

次のステップ

GitHub Actions は、アプリケーション開発プロセスのほぼすべての要素を自動化するのに役立ちます。 使い始める準備はできていますか。 GitHub Actions で次のステップに進む際に役立つ、以下のようなリソースを参照してください。

• GitHub Actions ワークフローの作成については、「ワークフロー テンプレートの使用」を参照してください。
• 継続的インテグレーション (CI) ワークフローについては、「ビルドとテスト」を参照してください。
• パッケージのビルドと発行については、「パッケージを公開する」を参照してください。
• プロジェクトの配置については、「ユース ケースと例」を参照してください。
• GitHub でタスクとプロセスを自動化する方法については、「プロジェクトの管理」を参照してください。
• GitHub Actions のより複雑な機能を示す例については、「ユース ケースと例」を参照してください。 これらの詳細な例では、ランナーでコードをテストする方法、GitHub CLI にアクセスする方法、コンカレンシーやテスト マトリックスなどの高度な機能を使用する方法を説明しています。

参考資料

• 「エンタープライズの GitHub Actions について」