Skip to main content

Understanding GitHub Actions

Learn the basics of GitHub Actions, including core concepts and essential terminology.


GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。 You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

GitHub Actions goes beyond just DevOps and lets you run workflows when other events happen in your repository. For example, you can run a workflow to automatically add the appropriate labels whenever someone creates a new issue in your repository.

GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure.

For more information about introducing GitHub Actions to your enterprise, see "Introducing GitHub Actions to your enterprise."

The components of GitHub Actions

You can configure a GitHub Actions workflow to be triggered when an event occurs in your repository, such as a pull request being opened or an issue being created. Your workflow contains one or more jobs which can run in sequential order or in parallel. Each job will run inside its own virtual machine runner, or inside a container, and has one or more steps that either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.

Workflow overview


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

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

You can reference a workflow within another workflow, see "Reusing workflows."

For more information about workflows, see "Using workflows."


An event is a specific activity in a repository that triggers a workflow run. For example, activity can originate from GitHub when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow run on a schedule, by posting to a REST API, or manually.

For a complete list of events that can be used to trigger workflows, see Events that trigger workflows.


A job is a set of steps in a workflow that execute on the same runner. Each step is either a shell script that will be executed, or an action that will be run. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built.

You can configure a job's dependencies with other jobs; by default, jobs have no dependencies and run in parallel with each other. When a job takes a dependency on another job, it will wait for the dependent job to complete before it can run. For example, you may have multiple build jobs for different architectures that have no dependencies, and a packaging job that is dependent on those jobs. The build jobs will run in parallel, and when they have all completed successfully, the packaging job will run.

For more information about jobs, see "Using jobs."


An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your workflow files. An action can pull your git repository from GitHub, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider.

You can write your own actions, or you can find actions to use in your workflows in the GitHub Marketplace.

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

For more information, see "Creating actions."


ランナーは、ワークフローがトリガーされると実行されるサーバーです。 Each runner can run a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows; each workflow run executes in a fresh, newly-provisioned virtual machine. GitHub also offers より大きなランナーs, which are available in larger configurations. For more information, see "Using より大きなランナーs." If you need a different operating system or require a specific hardware configuration, you can host your own runners. For more information about self-hosted runners, see "Hosting your own runners."


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

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

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

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

    name: learn-github-actions
    on: [push]
        runs-on: ubuntu-latest
          - uses: actions/checkout@v3
          - uses: actions/setup-node@v3
              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 のワークフロー構文」を参照してください。
learn-github-actions ワークフローで実行されるすべてのジョブをグループ化します。
check-bats-version という名前のジョブを定義します。 子キーは、ジョブのプロパティを定義します。
  runs-on: ubuntu-latest
Ubuntu Linux ランナーの最新バージョンで実行されるようにジョブを構成します。 これは、ジョブが GitHub によってホストされている新しい仮想マシンで実行されるということです。 他のランナーを使う構文例については、「GitHub Actions のワークフロー構文」を参照してください。
check-bats-version ジョブで実行されるすべてのステップをグループ化します。 このセクションで入れ子になった各項目は、個別のアクションまたはシェル スクリプトです。
    - uses: actions/checkout@v3
uses キーワードは、このステップが actions/checkout アクションの v3 を実行することを指定します。 これは、リポジトリをランナーにチェックアウトするアクションであり、コードに対してスクリプトまたは他のアクション (ビルド ツールやテスト ツールなど) を実行できます。 チェックアウト アクションは、リポジトリのコードに対してワークフローが実行されるたびに使用する必要があります。
    - uses: actions/setup-node@v3
        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. で、リポジトリのメイン ページへ移動します。

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


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


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


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


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


More complex examples

GitHub Actions のより複雑な機能を示す例については、「」を参照してください。 ランナーでコードをテストする方法、GitHub CLI にアクセスする方法、コンカレンシーやテスト マトリックスなどの高度な機能を使用する方法を説明する詳しい例を確認できます。

Next steps

Contacting support

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

GitHub Actionsについてのフィードバックもしくは機能リクエストがあるなら、それらをGitHub Actions に関する GitHub コミュニティのディスカッションで共有してください。

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

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

Further reading