Skip to main content

Understanding GitHub Actions

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

ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情報を見ることができます。


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.

You must host your own Linux, Windows, or macOS virtual machines to run workflows for GitHub Enterprise Serverインスタンス. セルフホストランナーは、物理、仮想、コンテナ内、オンプレミス、クラウドにできます。

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

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.



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

ワークフローはリポジトリ中の.github/workflowsディレクトリで定義され、1つのリポジトリに複数のワークフローを持たせ、それぞれが様々なタスクのセットを実行するようにできます。 たとえば、1つのワークフローで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.



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.

アクションを公開することなくEnterprise内で共有するには、そのアクションをインターナルリポジトリに保存し、同じOrganizationもしくはEnterprise内の任意のOrganizationが所有する他のリポジトリ内のGitHub Actionsワークフローからそのリポジトリへのアクセスを許可するよう設定します。 詳しい情報については「Entepriseでのアクションとワークフローの共有」を参照してください。



ランナーは、トリガーされたときにワークフローを実行するサーバーです。 Each runner can run a single job at a time. You must host your own runners for GitHub Enterprise Server. For more information, see "Hosting your own runners."


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

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

  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 リポジトリの [Actions] タブに表示されるワークフローの名前。
on: [push]
このワークフローのトリガーを指定します。 この例はpushイベントを使っているので、ワークフローの実行は誰かが変更をリポジトリにプッシュするか、Pull Requestをマージするたびにトリガーされます。 これは、すべてのブランチに対するプッシュによってトリガーされます。特定のブランチ、パス、タグへのプッシュでのみ実行するための構文の例については「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アクションを使ってNode.jsの指定されたバージョンをインストールします(この例ではv14が使われます)。 これは、node及びnpmコマンドをどちらもPATHに置きます。
    - run: npm install -g bats
run キーワードは、ランナーでコマンドを実行するようにジョブに指示します。 この場合、npm を使用して bats ソフトウェアテストパッケージをインストールしています。
    - run: bats -v
最後に、ソフトウェアバージョンを出力するパラメータを指定して bats コマンドを実行します。


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



ワークフローがトリガーされると、ワークフローを実行するワークフローの実行が生成されます。 ワークフローの実行が開始されると、実行の進行の可視化グラフを見ることができ、GitHub上の各ステップのアクティビティを表示できます。

  1. GitHub Enterprise Serverインスタンスで、リポジトリのメインページにアクセスしてください。

  2. リポジトリ名の下でActions(アクション)をクリックしてください。


  3. 左のサイドバーで、表示させたいワークフローをクリックしてください。


  4. "Workflow runs(ワークフローの実行)"の下で、表示させたい実行の名前をクリックしてください。


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


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


More complex examples

GitHub Actionsのさらに複雑な機能を紹介する例については「」を参照してください。 ランナー上でのコードのテストの方法、GitHub CLIへのアクセス、並行姓やテストマトリックスなどの高度な機能の使い方を説明する、詳細な例があります。



If you need help with anything related to workflow configuration, such as syntax, GitHub-hosted runners, or building actions, look for an existing topic or start a new one in the GitHub Community's GitHub Actions and GitHub Packages category.

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

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

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