Skip to main content
ドキュメントへの更新が頻繁に発行されており、このページの翻訳はまだ行われている場合があります。 最新の情報については、「英語のドキュメント」を参照してください。

GitHub Actions を理解する

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

注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

概要

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

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

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

GitHub Actions を Enterprise に導入する方法の詳細については、「Enterprise への GitHub Actions の導入」を参照してください。

GitHub Actions のコンポーネント

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

ワークフローの概要

Workflows

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

ワークフローはリポジトリ内の .github/workflows ディレクトリで定義され、リポジトリには複数のワークフローを含めることができます。各ワークフローは、それぞれ異なる一連のタスクを実行できます。 たとえば、あるワークフローでは、pull request をビルドしてテストし、別のワークフローでは、リリースが作成されるたびにアプリケーションをデプロイし、さらに別のワークフローでは、新しい issue が開かれるたびにラベルを追加することができます。

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

ワークフローの詳細については、「Using workflows」 (ワークフローの使用) を参照してください。

イベント

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

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

ジョブ

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

ジョブと他のジョブとの依存関係を構成できます。既定では、ジョブに依存関係はなく、相互に並列で実行されます。 ジョブが別のジョブに依存する場合、依存ジョブが完了するまで待ってから実行されます。 たとえば、異なるアーキテクチャ用で依存関係のない複数のビルド ジョブがあり、それらのジョブに依存するパッケージ化ジョブがあるとします。 ビルド ジョブは並列で実行され、それらがすべて正常に完了したら、パッケージ化ジョブが実行されます。

ジョブの詳細については、「Using jobs」 (ジョブの使用) を参照してください。

アクション

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

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

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

詳細については、「アクションを作成する」を参照してください。

ランナー

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

サンプルワークフローを作成する

GitHub Actions では、YAML 構文を使用してワークフローを定義します。 各ワークフローは、コード リポジトリ内の .github/workflows という名前のディレクトリに個別の YAML ファイルとして格納されます。

コードがプッシュされるたびに一連のコマンドを自動的にトリガーするサンプルワークフローをリポジトリに作成できます。 このワークフローでは、GitHub Actions がプッシュされたコードをチェックアウトし、bats テスト フレームワークをインストールし、bats バージョンを出力する基本コマンド bats -v を実行します。

  1. 自身のリポジトリで、ワークフロー ファイルを格納するための .github/workflows/ ディレクトリを作成します。

  2. .github/workflows/ ディレクトリで、learn-github-actions.yml という名前の新しいファイルを作成し、次のコードを追加します。

    YAML
    name: learn-github-actions
    on: [push]
    jobs:
      check-bats-version:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v3
          - uses: actions/setup-node@v3
            with:
              node-version: '14'
          - run: npm install -g bats
          - run: bats -v
  3. これらの変更をコミットして、GitHub リポジトリにプッシュします。

これで、新しい GitHub Actions ワークフローファイルがリポジトリにインストールされ、別のユーザがリポジトリに変更をプッシュするたびに自動的に実行されます。 ワークフローの実行履歴に関する詳細については、「ワークフロー実行時のアクティビティを見る」を参照してください。

ワークフローファイルを理解する

YAML 構文を使用してワークフローファイルを作成する方法を理解しやすくするために、このセクションでは、導入例の各行について説明します。

name: learn-github-actions
省略可能 - GitHub リポジトリの [アクション] タブに表示されるワークフローの名前。
on: [push]
このワークフローのトリガーを指定します。 この例では、push イベントを使用しているため、変更がリポジトリにプッシュされるか、pull request がマージされるたびに、ワークフロー実行がトリガーされます。 これは、すべてのブランチへのプッシュによってトリガーされます。特定のブランチ、パス、またはタブへのプッシュでのみ実行される構文の例については、「GitHub Actions のワークフロー構文」を参照してください。
jobs:
learn-github-actions ワークフローで実行されるすべてのジョブをグループ化します。
check-bats-version:
check-bats-version という名前のジョブを定義します。 子キーは、ジョブのプロパティを定義します。
  runs-on: ubuntu-latest
Ubuntu Linux ランナーの最新バージョンで実行されるようにジョブを構成します。 これは、ジョブが GitHub によってホストされている新しい仮想マシンで実行されるということです。 他のランナーを使う構文例については、「GitHub Actions のワークフロー構文」を参照してください。
  steps:
check-bats-version ジョブで実行されるすべてのステップをグループ化します。 このセクションで入れ子になった各項目は、個別のアクションまたはシェル スクリプトです。
    - uses: actions/checkout@v3
uses キーワードは、このステップが actions/checkout アクションの v3 を実行することを指定します。 これは、リポジトリをランナーにチェックアウトするアクションであり、コードに対してスクリプトまたは他のアクション (ビルド ツールやテスト ツールなど) を実行できます。 チェックアウト アクションは、リポジトリのコードに対してワークフローが実行されるたびに使用する必要があります。
    - uses: actions/setup-node@v3
      with:
        node-version: '14'
このステップでは、actions/setup-node@v3 アクションを使用して、指定されたバージョン (この例では、v14 を使用) の Node.js をインストールします。 これにより、nodenpm の両方のコマンドが PATH にプッシュされます。
    - run: npm install -g bats
run キーワードは、ランナーでコマンドを実行するようにジョブに指示します。 この場合は、npm を使用して bats ソフトウェア テスト パッケージをインストールします。
    - run: bats -v
最後に、ソフトウェアのバージョンを出力するパラメーターを指定して bats を実行します。

ワークフローファイルの視覚化

この図では、作成したワークフローファイルと、GitHub Actions コンポーネントが階層にどのように整理されているかを確認できます。 各ステップでは、単一のアクションまたはシェル スクリプトが実行されます。 ステップ 1 と 2 ではアクションが実行され、ステップ 3 と 4 ではシェル スクリプトが実行されます。 ワークフローの事前構築済みアクションの詳細については、「Finding and customizing actions」 (アクションの検出とカスタマイズ) を参照してください。

ワークフローの概要

ワークフロー実行のアクティビティの表示

ワークフローがトリガーされると、 ワークフローを実行するワークフロー実行 が作成されます。 ワークフロー実行の開始後に、実行の進行状況を示す視覚化グラフが表示され、GitHub での各ステップのアクティビティを表示できます。

  1. your GitHub Enterprise Server instance で、リポジトリのメイン ページへ移動します。

  2. リポジトリ名の下にある [アクション] をクリックします。

    リポジトリに移動

  3. 左サイドバーで、表示するワークフローをクリックします。

    ワークフロー結果のスクリーンショット

  4. [Workflow runs] で、表示する実行の名前をクリックします。

    ワークフロー実行のスクリーンショット

  5. [ジョブ] の下、または視覚化グラフ内で、表示するジョブをクリックします。

    ジョブを選択

  6. 各ステップの結果を表示します。

    ワークフロー実行の詳細のスクリーンショット

次の手順

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

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

サポートへの問い合わせ

構文、GitHub ホスト ランナー、アクションの構築など、ワークフローの構成に関して何か支援が必要な場合は、GitHub Community の GitHub Actions および GitHub Packages カテゴリで既存のトピックを探してみるか、新しいトピックを開始してください。

GitHub Actionsについてのフィードバックもしくは機能リクエストがあるなら、それらをGitHub Community discussions for GitHub Actionsで共有してください。

あなたの利用方法、もしくは意図する利用方法が利用制限のカテゴリに当てはまるかどうかに関わらず、以下のいずれかの場合はyour site administratorに連絡してください。

  • アカウントに間違った制約が課されていると思われる場合
  • いずれかのアクションを実行すると予期しないエラーが発生する場合
  • 既存の動作が期待される、ただし必ずしもドキュメント化されてはいない動作と矛盾するような状況に遭遇した場合

参考資料