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

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

ワークフローについて詳しくは、「ワークフローの使用」をご覧ください。

イベント

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

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

ジョブ

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

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

ジョブについて詳しくは、「ジョブの使用」をご覧ください。

アクション

アクション は、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
   run-name: ${{ github.actor }} is learning GitHub Actions
   on: [push]
   jobs:
     check-bats-version:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - uses: actions/setup-node@v4
           with:
             node-version: '14'
         - run: npm install -g bats
         - run: bats -v
   

3. これらの変更をコミットして、GitHub リポジトリにプッシュします。

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

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

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

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions
# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions

# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request.  This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]

# Groups together all the jobs that run in the `learn-github-actions` workflow.
jobs:

# Defines a job named `check-bats-version`. The child keys will define properties of the job.
  check-bats-version:

# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
    runs-on: ubuntu-latest

# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
    steps:

# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
      - uses: actions/checkout@v4

# This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 14.) This puts both the `node` and `npm` commands in your `PATH`.
      - uses: actions/setup-node@v4
        with:
          node-version: '14'

# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
      - run: npm install -g bats

# Finally, you'll run the `bats` command with a parameter that outputs the software version.
      - run: bats -v

name: learn-github-actions

run-name: ${{ github.actor }} is learning GitHub Actions

on: [push]

jobs:

  check-bats-version:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '14'

      - run: npm install -g bats

      - run: bats -v

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions
# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions

# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request.  This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]

# Groups together all the jobs that run in the `learn-github-actions` workflow.
jobs:

# Defines a job named `check-bats-version`. The child keys will define properties of the job.
  check-bats-version:

# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
    runs-on: ubuntu-latest

# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
    steps:

# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
      - uses: actions/checkout@v4

# This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 14.) This puts both the `node` and `npm` commands in your `PATH`.
      - uses: actions/setup-node@v4
        with:
          node-version: '14'

# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
      - run: npm install -g bats

# Finally, you'll run the `bats` command with a parameter that outputs the software version.
      - run: bats -v

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

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

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

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

1. お使いの GitHub Enterprise Server インスタンス で、リポジトリのメイン ページへ移動します。

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

   

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

   

4. ワークフロー実行の一覧で実行の名前をクリックすると、ワークフロー実行の概要が表示されます。

5. 左側のサイドバーまたは視覚化グラフで、表示するジョブをクリックします。

6. ステップの結果を表示するには、ステップをクリックします。

次の手順

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

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

参考資料

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