GitHub Actionsについて

GitHub Actions のコア概念や重要な用語の基本について説明します。

この記事で

メモ

GitHub ホステッド ランナーは、現在 GitHub Enterprise Server ではサポートされていません。

概要

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

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

お使いの GitHub Enterprise Server インスタンス のワークフローを実行するには、独自の Linux、Windows、または macOS 仮想マシンをホストする必要があります。

Enterprise に GitHub Actions を導入方法の詳細については、「企業向けGitHub Actionsの導入」を参照してください。

GitHub Actions のコンポーネント

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

ランナー 1 をトリガーしてジョブ 1 を実行し、それによってランナー 2 がジョブ 2 の実行をトリガーするイベントの図。 各ジョブは複数のステップに分割されています。

ワークフロー

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

ワークフローは、リポジトリ内の .github/workflows ディレクトリで定義されます。 1 つのリポジトリで複数のワークフローを使用でき、それぞれで次のような異なるタスクのセットを実行できます。

  • Pull request のビルドとテスト
  • リリースが作成される度にアプリケーションを配置する
  • 新しい issue が開かれる度にラベルを追加する

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

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

イベント

          **イベント**とは、**ワークフロー**実行をトリガーする、リポジトリ内の特定のアクティビティです。 たとえば、pull request が作成されたとき、issue が開かれたとき、またはリポジトリにコミットがプッシュされたときに、GitHub からアクティビティを発生させることができます。 また、[[スケジュール]](/actions/using-workflows/events-that-trigger-workflows#schedule) に従って、[[REST API に投稿]](/rest/repos/repos#create-a-repository-dispatch-event) または手動で、ワークフロー実行を作動させることもできます。

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

ジョブ

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

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

また、マトリックスを使用すると、オペレーティング システムや言語のバージョンなど、変数の組み合わせをそれぞれ変えて同じジョブを複数回実行することもできます。

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

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

アクション

          **アクション**は、**ワークフロー**内で特定のタスクを実行する、再利用可能な定義済みジョブまたはコードのセットです。これによりワークフロー ファイルに記述する繰り返しコードの量を減らすことができます。 アクションは、次のようなタスクを実行することができます。
  • Git リポジトリをGitHubからプルする
  • ビルド環境のツールチェーンの設定
  • クラウド プロバイダーに対する認証の設定

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

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

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

ランナー

          **ランナー**とは、ワークフローがトリガーされると実行されるサーバーです。 各ランナーは一度に 1 つの**ジョブ**を実行できます。

GitHub Enterprise Server の場合、独自のランナーをホストする必要があります。

詳細については、「セルフホステッド ランナーの管理」を参照してください。

次のステップ

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

参考資料

  •         [AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/about-github-actions-for-enterprises)