GitHub Actionsについて

メモ

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

概要

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

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



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

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

          GitHub Actionsのコンポーネント

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

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

ワークフロー

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

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

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

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

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

イベント

          **イベント**とは、**ワークフロー**実行をトリガーする、リポジトリ内の特定のアクティビティです。 たとえば、アクティビティは、誰かが pull request を作成したり、問題を開いたり、リポジトリにコミットをプッシュしたりしたときに、 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 で次のステップに進む際に役立つ、以下のようなリソースを参照してください。

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

参考資料

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

この記事で