概要
GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。 リポジトリに対するすべての pull request をビルドしてテストしたり、マージされた pull request を運用環境にデプロイしたりするワークフローを作成できます。
GitHub Actions は、DevOps であるだけでなく、リポジトリで他のイベントが発生したときにワークフローを実行できます。 たとえば、リポジトリで新しい issue が作成されるたびに、適切なラベルを自動的に追加するワークフローを実行できます。
GitHub では、ワークフローを実行するための Linux、Windows、macOS 仮想マシンが提供されます。また、自身のデータセンターまたはクラウド インフラストラクチャで独自のセルフホスト ランナーをホストすることもできます。
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 で、ワークフローで使用するアクションを見つけることもできます。
アクションの詳細については、「自動化の共有」を参照してください。
ランナー
ランナーとは、ワークフローがトリガーされると実行されるサーバーです。 各ランナーは一度に 1 つのジョブを実行できます。 GitHub では、ワークフローを実行するための Ubuntu Linux、Microsoft Windows、macOS ランナーを提供しています。 各ワークフロー実行は、新しくプロビジョニングされた仮想マシンで実行されます。
GitHub には、より大きな構成で使うことができる より大きなランナー も用意されています。 詳しくは、「より大きなランナーの使用」をご覧ください。
別のオペレーティング システムが必要な場合、または特定のハードウェア設定が必要な場合は、独自のランナーをホストできます。
自己ホストランナーの詳細については、「自分のランナーをホストする」を参照してください。
次のステップ
GitHub Actions は、アプリケーション開発プロセスのほぼすべての要素を自動化するのに役立ちます。 使い始める準備はできていますか。 GitHub Actions で次のステップに進む際に役立つ、以下のようなリソースを参照してください。
- GitHub Actions ワークフローの作成については、「ワークフロー テンプレートの使用」を参照してください。
- 継続的インテグレーション (CI) ワークフローについては、「ビルドとテスト」を参照してください。
- パッケージのビルドと発行については、「パッケージを公開する」を参照してください。
- プロジェクトの配置については、「ユース ケースと例」を参照してください。
- GitHub でタスクとプロセスを自動化する方法については、「プロジェクトの管理」を参照してください。
- GitHub Actions のより複雑な機能を示す例については、「ユース ケースと例」を参照してください。 これらの詳細な例では、ランナーでコードをテストする方法、GitHub CLI にアクセスする方法、コンカレンシーやテスト マトリックスなどの高度な機能を使用する方法を説明しています。
- GitHub Certifications で GitHub Actions 認定を取得すると、GitHub Actions を使用してワークフローを自動化し、開発を加速する能力を証明できます。 詳しくは、「GitHub Certifications について」をご覧ください。