Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい

ワークフローをトリガーするイベント

GitHub Enterprise Server で特定のアクティビティが実行された時、スケジュールした時間、または GitHub Enterprise Server 外でイベントが発生した時にワークフローを実行できるよう設定できます。

ワークフローをトリガーするイベントについて

ワークフロー トリガーは、ワークフローの実行を引き起こすイベントです。 ワークフロー トリガーの使い方の詳細については、「ワークフローのトリガー」を参照してく� さい。

使用できるイベント

イベントによっては、複数のアクティビティの種類があります。 このようなイベントでは、ワークフローの実行をトリガーするアクティビティの種類を指定できます。 アクティビティの種類それぞれの意味の詳細については、「Webhook イベントとペイロード」を参照してく� さい。 すべての Webhook イベントでワークフローがトリガーされるわけではないことに注意してく� さい。

check_run

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
check_run- created
- rerequested
- completed
-requested_action
デフォルトブランチの直近のコミットデフォルトブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

チェック実行に関連するアクティビティが発生したときにワークフローを実行します。 チェックの実行は、個別のテストであり、チェックスイートの一機能です。 詳細については、「Checks API を使ってみる」を参照してく� さい。 チェック実行 API については、GraphQL API ドキュメントの「CheckRun」または REST API ドキュメントの「チェック」を参照してく� さい。

たとえば、チェック実行が rerequested または completed � ったときにワークフローを実行できます。

on:
  check_run:
    types: [rerequested, completed]

check_suite

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
check_suite- completedデフォルトブランチの直近のコミットデフォルトブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 アクティビティの種類 started のみがサポートされていますが、このアクティビティの種類を指定すると、今後さらにアクティビティの種類が追� された� �合に、ワークフローを特定のもののままにできます。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

注: 再帰的なワークフローを避けるために、GitHub Actions によってチェック スイートが作成された� �合にはこのイベントによってワークフローはトリガーされません。

チェック スイートのアクティビティが発生したときにワークフローを実行します。 チェック スイートは、特定のコミットに対して作成されたチェック実行のコレクションです。 チェック スイートでは、スイート内のチェック実行の状態と結果をまとめます。 詳細については、「Checks API を使ってみる」を参照してく� さい。 チェック スイート API の詳細については、GraphQL API ドキュメントの「CheckSuite」または REST API ドキュメントの「チェック」を参照してく� さい。

たとえば、チェック スイートが completed � ったときにワークフローを実行できます。

on:
  check_suite:
    types: [completed]

create

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
create該当なし直近でブランチまたはタグが作成されたコミット作成されたブランチまたはタグ

: 一度に 3 つを超えるタグを作成した� �合、イベントは作成されません。

誰かがワークフローのリポジトリに Git 参照 (Git ブランチまたはタグ) を作成したときにワークフローを実行します。 Git 参照を作成する API については、GraphQL API ドキュメントの「createRef」または REST API ドキュメントの「参照の作成」を参照してく� さい。

たとえば、create イベントが発生したときにワークフローを実行できます。

on:
  create

delete

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
delete該当なしデフォルトブランチの直近のコミットデフォルトブランチ

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

: 一度に 3 つを超えるタグを削除した� �合、イベントは作成されません。

誰かがワークフローのリポジトリで Git 参照 (Git ブランチまたはタグ) を削除したときにワークフローを実行します。 Git 参照を削除する API については、GraphQL API ドキュメントの「deleteRef」または REST API ドキュメントの「参照の削除」を参照してく� さい。

たとえば、delete イベントが発生したときにワークフローを実行できます。

on:
  delete

deployment

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
deployment該当なしデプロイされるコミットデプロイするブランチまたはタグ (コミット SHA 付きで作成された� �合は空)

誰かがワークフローのリポジトリにデプロイを作成したときにワークフローを実行します。 コミット SHA 付きで作成されたデプロイには Git 参照がないことがあります。デプロイを作成する API については、GraphQL API ドキュメントの「createDeployment」または REST API ドキュメントの「デプロイ」を参照してく� さい。

たとえば、deployment イベントが発生したときにワークフローを実行できます。

on:
  deployment

deployment_status

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
deployment_status該当なしデプロイされるコミットデプロイされるブランチまたはタグ (コミットの� �合は空)

注: デプロイの状態が inactive に設定されている� �合、ワークフローの実行はトリガーされません。

サード パーティによってデプロイの状態が提供されたときにワークフローを実行します。 コミット SHA 付きで作成されたデプロイには Git 参照がないことがあります。デプロイの状態を作成する API については、GraphQL API ドキュメントの「createDeploymentStatus」または REST API ドキュメントのデプロイの状態の作成に関する記事を参照してく� さい。

たとえば、deployment_status イベントが発生したときにワークフローを実行できます。

on:
  deployment_status

fork

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
fork該当なしデフォルトブランチの直近のコミットデフォルトブランチ

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

誰かがリポジトリをフォークしたときにワークフローを実行します。 REST API については、「フォークの作成」を参照してく� さい。

たとえば、fork イベントが発生したときにワークフローを実行できます。

on:
  fork

gollum

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
gollum該当なしデフォルトブランチの直近のコミットデフォルトブランチ

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

誰かが Wiki ページを作成または更新したときにワークフローを実行します。 詳細については、wiki についてに関する記事を参照してく� さい。

たとえば、gollum イベントが発生したときにワークフローを実行できます。

on:
  gollum

issue_comment

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
issue_comment- created
- edited
- deleted
デフォルトブランチの直近のコミットデフォルトブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

issue または pull request のコメントが作成、編集、または削除されたときにワークフローを実行します。 issue コメント API については、GraphQL API ドキュメントの「IssueComment」または REST API ドキュメントの issue コメントに関するページを参照してく� さい。

たとえば、issue または pull request のコメントが created または deleted � ったときにワークフローを実行できます。

on:
  issue_comment:
    types: [created, deleted]

issue のみまたは pull request のみの issue_comment

issue_comment イベントは、issue と pull request の両方に関するコメントで発生します。 条件で github.event.issue.pull_request プロパティを使うと、トリガーするオブジェクトが issue か pull request かによって異なるアクションを実行できます。

たとえば、このワークフローでは、issue_comment イベントが pull request から発生した� �合にのみ pr_commented ジョブを実行します。 issue_comment イベントが issue から発生した� �合にのみ issue_commented ジョブが実行されます。

on: issue_comment

jobs:
  pr_commented:
    # This job only runs for pull request comments
    name: PR comment
    if: ${{ github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on PR $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

  issue_commented:
    # This job only runs for issue comments
    name: Issue comment
    if: ${{ !github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on issue $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

issues

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
issues- opened
- edited
- deleted
- transferred
- pinned
- unpinned
- closed
- reopened
- assigned
- unassigned
- labeled
- unlabeled
- locked
- unlocked
- milestoned
- demilestoned
デフォルトブランチの直近のコミットデフォルトブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

ワークフローのリポジトリ内の issue が作成または変更されたときにワークフローを実行します。 issue のコメントに関連するアクティビティには、issue_comment イベントを使います。 issue の詳細については、「Issue について」を参照してく� さい。 issue API については、GraphQL API ドキュメントの「Issue」または REST API ドキュメントの「Issue」を参照してく� さい。

たとえば、issue が openededited、または milestoned � ったときにワークフローを実行できます。

on:
  issues:
    types: [opened, edited, milestoned]

label

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
label- created
- edited
- deleted
デフォルトブランチの直近のコミットデフォルトブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

ワークフローのリポジトリ内のラベルが作成または変更されたときにワークフローを実行します。 ラベルの詳細については、「ラベルを管理する」を参照してく� さい。 ラベル API については、GraphQL API ドキュメントの「Label」または REST API ドキュメントの「ラベル」を参照してく� さい。

issue、pull request、またはディスカッションに対してラベルが追� または削除されたときにワークフローを実行する� �合は、代わりに issuespull_requestpull_request_target、または discussion イベントにはアクティビティの種類 labeled または unlabeled を使います。

たとえば、ラベルが created または deleted � ったときにワークフローを実行できます。

on:
  label:
    types: [created, deleted]

milestone

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
milestone- created
- closed
- opened
- edited
- deleted
デフォルトブランチの直近のコミットデフォルトブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

ワークフローのリポジトリ内のマイルストーンが作成または変更されたときにワークフローを実行します。 マイルストーンの詳細については、「マイルストーンについて」を参照してく� さい。 マイルストーン API については、GraphQL API ドキュメントの「Milestone」または REST API ドキュメントの「マイルストーン」を参照してく� さい。

マイルストーンに対して issue が追� または削除されたときにワークフローを実行する� �合は、代わりに issues イベントにはアクティビティの種類 milestoned または demilestoned を使います。

たとえば、マイルストーンが opened または deleted � ったときにワークフローを実行できます。

on:
  milestone:
    types: [opened, deleted]

page_build

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
page_build該当なしデフォルトブランチの直近のコミット該当なし

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

リポジトリに対して GitHub Pages が有効になっている� �合、GitHub Pages の公開元であるブランチに誰かがプッシュしたときにワークフローを実行します。 GitHub Pages の公開元の詳細については、「GitHub Pages サイトの公開元を設定する」を参照してく� さい。 REST API については、ページに関するページを参照してく� さい。

たとえば、page_build イベントが発生したときにワークフローを実行できます。

on:
  page_build

project

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
project- created
- closed
- reopened
- edited
- deleted
デフォルトブランチの直近のコミットデフォルトブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 アクティビティの種類 edited は、プロジェクト ボードの列またはカードではなくプロジェクト ボードが編集されたときに参照されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

: このイベントは、組織所有またはユーザー所有のプロジェクトや、別のリポジトリで所有するプロジェクトではなく、ワークフローのリポジトリで所有するプロジェクトに対してのみ発生します。

プロジェクト ボードが作成または変更されたときにワークフローを実行します。 プロジェクト ボードのカードまたは列に関連するアクティビティには、代わりに project_card または project_column イベントを使います。 プロジェクト ボードの詳細については、「プロジェクト ボードについて」を参照してく� さい。 プロジェクト ボード API については、GraphQL API ドキュメントの「Project」または REST API ドキュメントの「プロジェクト」を参照してく� さい。

たとえば、プロジェクトが created または deleted � ったときにワークフローを実行できます。

on:
  project:
    types: [created, deleted]

project_card

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
project_card- created
- moved
問題に - converted
- edited
- deleted
デフォルトブランチの直近のコミットデフォルトブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

: このイベントは、組織所有またはユーザー所有のプロジェクトや、別のリポジトリで所有するプロジェクトではなく、ワークフローのリポジトリで所有するプロジェクトに対してのみ発生します。

プロジェクト ボード上のカードが作成または変更されたときにワークフローを実行します。 プロジェクト ボードまたはプロジェクト ボードの列に関連するアクティビティには、代わりに project または project_column イベントを使います。 プロジェクト ボードの詳細については、「プロジェクト ボードについて」を参照してく� さい。 プロジェクト カード API については、GraphQL API ドキュメントの「ProjectCard」または REST API ドキュメントのプロジェクト カードに関するページを参照してく� さい。

たとえば、プロジェクト カードが created または deleted � ったときにワークフローを実行できます。

on:
  project_card:
    types: [created, deleted]

project_column

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
project_column- created
- updated
- moved
- deleted
デフォルトブランチの直近のコミットデフォルトブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

: このイベントは、組織所有またはユーザー所有のプロジェクトや、別のリポジトリで所有するプロジェクトではなく、ワークフローのリポジトリで所有するプロジェクトに対してのみ発生します。

プロジェクト ボード上の列が作成または変更されたときにワークフローを実行します。 プロジェクト ボードまたはプロジェクト ボードのカードに関連するアクティビティには、代わりに project または project_card イベントを使います。 プロジェクト ボードの詳細については、「プロジェクト ボードについて」を参照してく� さい。 プロジェクト列 API については、GraphQL API ドキュメントの「ProjectColumn」または REST API ドキュメントのプロジェクト列に関するページを参照してく� さい。

たとえば、プロジェクト列が created または deleted � ったときにワークフローを実行できます。

on:
  project_column:
    types: [created, deleted]

public

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
public該当なしデフォルトブランチの直近のコミットデフォルトブランチ

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

ワークフローのリポジトリがプライベートからパブリックに変更されたときにワークフローを実行します。 REST API については、「リポジトリの編集」を参照してく� さい。

たとえば、public イベントが発生したときにワークフローを実行できます。

on:
  public

pull_request

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
pull_request- assigned
- unassigned
- labeled
- unlabeled
- opened
- edited
- closed
- reopened
- synchronize
- converted_to_draft
- ready_for_review
- locked
- unlocked
- review_requested
- review_request_removed
- auto_merge_enabled
- auto_merge_disabled
GITHUB_REF ブランチでの最後のマージ コミットPR マージ ブランチ refs/pull/:prNumber/merge

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、ワークフローは、pull_request イベントのアクティビティの種類が openedsynchronize、または reopened の� �合にのみ実行されます。 さまざまなアクティビティの種類でワークフローをトリガーするには、types キーワードを使います。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: pull request にマージの競合がある� �合、pull_request アクティビティではワークフローは実行されません。 マージの競合を最初に解決する必要があります。

逆に、pull_request_target イベントを含むワークフローは、pull request にマージの競合がある� �合でも実行されます。 pull_request_target トリガーを使う前に、セキュリティ リスクに注意する必要があります。 詳細については、「pull_request_target」を参照してく� さい。

ワークフローのリポジトリ内の pull request のアクティビティが発生したときにワークフローを実行します。 たとえば、アクティビティの種類が指定されていない� �合、pull request を開いたり、再度開いたりしたとき、または pull request の head ブランチが更新されたときにワークフローが実行されます。 pull request レビュー、pull request レビュー コメント、または pull request コメントに関連するアクティビティには、代わりに pull_request_reviewpull_request_review_comment、または issue_comment イベントを使います。 pull request API については、GraphQL API ドキュメントの「PullRequest」または REST API ドキュメントの Pull request に関するトピックを参照してく� さい。

このイベントの GITHUB_SHA が pull request マージ ブランチの最後のマージ コミットであることに注意してく� さい。 pull request の head ブランチへの最後のコミットのコミット ID を取得する� �合は、代わりに github.event.pull_request.head.sha を使います。

たとえば、pull request を開いたり再度開いたりしたときにワークフローを実行できます。

on:
  pull_request:
    types: [opened, reopened]

イベント コンテキストを使って、ワークフロー内のジョブを実行するタイミングをさらに制御できます。 たとえば、このワークフローは pull request でレビューが要求されたときに実行されますが、specific_review_requested ジョブは octo-team によるレビューの要求時にのみ実行されます。

on:
  pull_request:
    types: [review_requested]
jobs:
  specific_review_requested:
    runs-on: ubuntu-latest
    if: ${{ github.event.requested_team.name == 'octo-team'}}
    steps:
      - run: echo 'A review from octo-team was requested'

pull request の head またはベース ブランチに基づいてワークフローを実行する

branches または branches-ignore フィルターを使って、特定のブランチを対象とする pull request でのみ実行するようにワークフローを構成できます。 詳細については、「GitHub Actions のワークフロー構文」を参照してく� さい。

たとえば、このワークフローは、名前が releases/ で始まるブランチを対象とする pull request を誰かが開いたときに実行されます。

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'

注: branches フィルターと paths フィルターの両方を使用する� �合、ワークフローは両方のフィルターが満たされた� �合にのみ実行されます。 たとえば、次のワークフローは、JavaScript (.js) ファイルへの変更を含む pull request が、名前が releases/ で始まるブランチで開かれた� �合にのみ実行されます。

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

(pull request のベース ブランチ名ではなく) pull request の head ブランチ名に基づいてジョブを実行するには、条件で github.head_ref コンテキストを使います。 たとえば、このワークフローは pull request が開かれるたびに実行されますが、pull request の head が releases/ で始まる名前のブランチである� �合にのみ run_if ジョブが実行されます。

on:
  pull_request:
    types:
      - opened
jobs:
  run_if:
    if:  startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

pull request で変更されたファイルに基づいてワークフローを実行する

また、pull request によって特定のファイルが変更されたときに実行するようにワークフローを構成することもできます。 詳細については、「GitHub Actions のワークフロー構文」を参照してく� さい。

たとえば、このワークフローは、pull request に JavaScript ファイル (.js) への変更が含まれているときに実行されます。

on:
  pull_request:
    paths:
      - '**.js'

注: branches フィルターと paths フィルターの両方を使用する� �合、ワークフローは両方のフィルターが満たされた� �合にのみ実行されます。 たとえば、次のワークフローは、JavaScript (.js) ファイルへの変更を含む pull request が、名前が releases/ で始まるブランチで開かれた� �合にのみ実行されます。

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

pull request がマージされたときにワークフローを実行する

pull request がマージされると、pull request は自動的に閉じられます。 pull request のマージ時にワークフローを実行するには、イベントの merged 値を検査する条件とともにイベントの種類 pull_request``closed を使います。 たとえば、次のワークフローは、pull request が閉じるたびに実行されます。 if_merged ジョブは、pull request もマージされた� �合にのみ実行されます。

on:
  pull_request:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged

フォークされたリポジトリのワークフロー

デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 GitHub アクションは、フォークされたリポジトリの [アクション] タブで有効にする必要があります。

GITHUB_TOKEN の例外を除き、ワークフローがフォークされたリポジトリからトリガーされた� �合、シークレットはランナーに渡されません。 GITHUB_TOKEN には、フォークされたリポジトリの読み取り専用アクセス許可があります。 詳細については、「GITHUB_TOKEN を使用した認証」を参照してく� さい。

フォークしたリポジトリのプルリクエストイベント

フォークされたリポジトリからベースリポジトリへの pull request の� �合、GitHub Enterprise Server は、ベースリポジトリに pull_requestissue_commentpull_request_review_commentpull_request_reviewpull_request_target イベントを送信します。 フォークされたリポジトリでは、pull request イベントは発生しません。

注: フォークされたリポジトリで pull request をオープンした� �合には、プライベートのベースリポジトリではワークフローは実行されません。

注: Dependabot の pull request によってトリガーされたワークフローは、フォークされたリポジトリからのもののように扱われ、これらの制約を受けます。

pull_request_comment (issue_comment を使用)

(pull request の差分ではなく) pull request のコメントが作成、編集、または削除されたときにワークフローを実行するには、issue_comment イベントを使います。 pull request レビューまたは pull request レビュー コメントに関連するアクティビティには、pull_request_review または pull_request_review_comment イベントを使います。

pull_request_review

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
pull_request_review- submitted
- edited
- dismissed
GITHUB_REF ブランチでの最後のマージ コミットPR マージ ブランチ refs/pull/:prNumber/merge

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

pull request レビューが送信、編集、または無視されたときにワークフローを実行します。 pull request レビューは、本文コメントと状態に� えて、pull request レビュー コメントのグループです。 pull request レビュー コメントまたは pull request コメントに関連するアクティビティには、代わりに pull_request_review_comment または issue_comment イベントを使います。 pull request レビュー API については、GraphQL API ドキュメントの「PullRequestReview」または REST API ドキュメントの「Pull request のレビュー」を参照してく� さい。

たとえば、pull request レビューが edited または dismissed � ったときにワークフローを実行できます。

on:
  pull_request_review:
    types: [edited, dismissed]

pull request が承認されたときにワークフローを実行する

pull request が承認されたときにワークフローを実行するには、種類 submittedpull_request_review イベントを使ってワークフローをトリガーし、github.event.review.state プロパティを使ってレビューの状態を確認します。 たとえば、このワークフローは pull request レビューが送信されるたびに実行されますが、approved ジョブは、送信されたレビューが承認レビューである� �合にのみ実行されます。

on:
  pull_request_review:
    types: [submitted]

jobs:
  approved:
    if: github.event.review.state == 'approved'
    runs-on: ubuntu-latest
    steps:
      - run: echo "This PR was approved"

フォークされたリポジトリのワークフロー

デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 GitHub アクションは、フォークされたリポジトリの [アクション] タブで有効にする必要があります。

GITHUB_TOKEN の例外を除き、ワークフローがフォークされたリポジトリからトリガーされた� �合、シークレットはランナーに渡されません。 GITHUB_TOKEN には、フォークされたリポジトリの読み取り専用アクセス許可があります。 詳細については、「GITHUB_TOKEN を使用した認証」を参照してく� さい。

フォークしたリポジトリのプルリクエストイベント

フォークされたリポジトリからベースリポジトリへの pull request の� �合、GitHub Enterprise Server は、ベースリポジトリに pull_requestissue_commentpull_request_review_commentpull_request_reviewpull_request_target イベントを送信します。 フォークされたリポジトリでは、pull request イベントは発生しません。

注: フォークされたリポジトリで pull request をオープンした� �合には、プライベートのベースリポジトリではワークフローは実行されません。

注: Dependabot の pull request によってトリガーされたワークフローは、フォークされたリポジトリからのもののように扱われ、これらの制約を受けます。

pull_request_review_comment

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
pull_request_review_comment- created
- edited
- deleted
GITHUB_REF ブランチでの最後のマージ コミットPR マージ ブランチ refs/pull/:prNumber/merge

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

pull request レビュー コメントが変更されたときにワークフローを実行します。 pull request レビュー コメントは、pull request の差分に関するコメントです。 pull request レビューまたは pull request コメントに関連するアクティビティには、代わりに pull_request_review または issue_comment イベントを使います。 pull request レビュー コメント API については、GraphQL API ドキュメントの「PullRequestReviewComment」または REST API ドキュメントのレビュー コメントに関するトピックを参照してく� さい。

たとえば、pull request レビュー コメントが created または deleted � ったときにワークフローを実行できます。

on:
  pull_request_review_comment:
    types: [created, deleted]

フォークされたリポジトリのワークフロー

デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 GitHub アクションは、フォークされたリポジトリの [アクション] タブで有効にする必要があります。

GITHUB_TOKEN の例外を除き、ワークフローがフォークされたリポジトリからトリガーされた� �合、シークレットはランナーに渡されません。 GITHUB_TOKEN には、フォークされたリポジトリの読み取り専用アクセス許可があります。 詳細については、「GITHUB_TOKEN を使用した認証」を参照してく� さい。

フォークしたリポジトリのプルリクエストイベント

フォークされたリポジトリからベースリポジトリへの pull request の� �合、GitHub Enterprise Server は、ベースリポジトリに pull_requestissue_commentpull_request_review_commentpull_request_reviewpull_request_target イベントを送信します。 フォークされたリポジトリでは、pull request イベントは発生しません。

注: フォークされたリポジトリで pull request をオープンした� �合には、プライベートのベースリポジトリではワークフローは実行されません。

注: Dependabot の pull request によってトリガーされたワークフローは、フォークされたリポジトリからのもののように扱われ、これらの制約を受けます。

pull_request_target

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
pull_request- assigned
- unassigned
- labeled
- unlabeled
- opened
- edited
- closed
- reopened
- synchronize
- converted_to_draft
- ready_for_review
- locked
- unlocked
- review_requested
- review_request_removed
- auto_merge_enabled
- auto_merge_disabled
PR ベースブランチの直近のコミットPR ベースブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、ワークフローは、pull_request_target イベントのアクティビティの種類が openedsynchronize、または reopened の� �合にのみ実行されます。 さまざまなアクティビティの種類でワークフローをトリガーするには、types キーワードを使います。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

ワークフローのリポジトリ内の pull request のアクティビティが発生したときにワークフローを実行します。 たとえば、アクティビティの種類が指定されていない� �合、pull request を開いたり、再度開いたりしたとき、または pull request の head ブランチが更新されたときにワークフローが実行されます。

このイベントは、pull_request イベントのようにマージ コミットのコンテキストではなく、pull request のベースのコンテキストで実行されます。 これで、リポジトリを変更したり、ワークフローで使うシークレットを盗ん� りする可能性がある、pull request の head から安全ではないコードが実行されるのが避けられます。 このイベントを使うと、ワークフローでは、pull request に対するラベルやコメントなどの作業をフォークから行うことができます。 pull request からコードをビルドまたは実行する必要がある� �合は、このイベントを使わないでく� さい。

リポジトリのセキュリティを維持するため、特定のパターン (SHA に似ているものなど) と一致する名前を持つブランチからは、pull_request_target イベントでワークフローがトリガーされない� �合があります。

警告: pull_request_target イベントによってトリガーされるワークフローでは、permissions キーが指定され、ワークフローがフォークからトリガーされてもシークレットにアクセスできる� �合を除き、読み取り/書き込みリポジトリのアクセス許可が GITHUB_TOKEN に付与されます。 ワークフローはPull Requestのベースのコンテキストで実行されますが、このイベントでPull Requestから信� �できないコードをチェックアウトしたり、ビルドしたり、実行したりしないようにしなければなりません。 さらに、キャッシュではベース ブランチと同じスコープを共有します。 キャッシュ ポイズニングを防ぐために、キャッシュの内容が変更された可能性がある� �合は、キャッシュを保存しないでく� さい。 詳細については、GitHub Security Lab の Web サイトの GitHub Actions およびワークフローのセキュリティ保護の維持: pwn 要求の阻止に関するページを参照してく� さい。

たとえば、pull request が assignedopenedsynchronize、または reopened � ったときにワークフローを実行できます。

on:
  pull_request_target:
    types: [assigned, opened, synchronize, reopened]

pull request の head またはベース ブランチに基づいてワークフローを実行する

branches または branches-ignore フィルターを使って、特定のブランチを対象とする pull request でのみ実行するようにワークフローを構成できます。 詳細については、「GitHub Actions のワークフロー構文」を参照してく� さい。

たとえば、このワークフローは、名前が releases/ で始まるブランチを対象とする pull request を誰かが開いたときに実行されます。

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'

注: branches フィルターと paths フィルターの両方を使用する� �合、ワークフローは両方のフィルターが満たされた� �合にのみ実行されます。 たとえば、次のワークフローは、JavaScript (.js) ファイルへの変更を含む pull request が、名前が releases/ で始まるブランチで開かれた� �合にのみ実行されます。

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

(pull request のベース ブランチ名ではなく) pull request の head ブランチ名に基づいてジョブを実行するには、条件で github.head_ref コンテキストを使います。 たとえば、このワークフローは pull request が開かれるたびに実行されますが、pull request の head が releases/ で始まる名前のブランチである� �合にのみ run_if ジョブが実行されます。

on:
  pull_request:
    types:
      - opened
jobs:
  run_if:
    if:  startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

pull request で変更されたファイルに基づいてワークフローを実行する

paths または paths-ignore フィルターを使って、pull request によって特定のファイルが変更されたときに実行するようにワークフローを構成することもできます。 詳細については、「GitHub Actions のワークフロー構文」を参照してく� さい。

たとえば、このワークフローは、pull request に JavaScript ファイル (.js) への変更が含まれているときに実行されます。

on:
  pull_request_target:
    paths:
      - '**.js'

注: branches フィルターと paths フィルターの両方を使用する� �合、ワークフローは両方のフィルターが満たされた� �合にのみ実行されます。 たとえば、次のワークフローは、JavaScript (.js) ファイルへの変更を含む pull request が、名前が releases/ で始まるブランチで開かれた� �合にのみ実行されます。

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

pull request がマージされたときにワークフローを実行する

pull request がマージされると、pull request は自動的に閉じられます。 pull request のマージ時にワークフローを実行するには、イベントの merged 値を検査する条件とともにイベントの種類 pull_request_target``closed を使います。 たとえば、次のワークフローは、pull request が閉じるたびに実行されます。 if_merged ジョブは、pull request もマージされた� �合にのみ実行されます。

on:
  pull_request_target:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged

push

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
push該当なしブランチを削除すると、ワークフロー実行の SHA (およびその関連する参照) がリポジトリの既定のブランチに戻ります。更新された ref

注: GitHub Actions で使用できる Webhook ペイロードには、commit オブジェクトの addedremovedmodified の各属性は含まれません。 完全な commit オブジェクトは、API を使って取得できます。 詳細については、GraphQL API ドキュメントの「Commit」または REST API ドキュメントのコミットの取得に関するトピックを参照してく� さい。

: 一度に 3 つを超えるタグをプッシュした� �合、イベントは作成されません。

コミットまたはタグをプッシュするときにワークフローを実行します。

たとえば、push イベントが発生したときにワークフローを実行できます。

on:
  push

: push Webhook イベントによってワークフローの実行がトリガーされると、Actions UI の [プッシュ元] フィールドには、作成者またはコミッターではなく、プッシャーのアカウントが表示されます。 一方、デプロイ キーによる SSH 認証を使って変更がリポジトリにプッシュされた� �合は、[プッシュ元] フィールドは、デプロイ キーがリポジトリに追� されたときにそれを確認したリポジトリ管理者になります。

特定のブランチへのプッシュが発生した� �合にのみワークフローを実行する

branches または branches-ignore フィルターを使って、特定のブランチがプッシュされたときにのみ実行するようにワークフローを構成できます。 詳細については、「GitHub Actions のワークフロー構文」を参照してく� さい。

たとえば、このワークフローは、main か、releases/ で始まるブランチに誰かがプッシュしたときに実行されます。

on:
  push:
    branches:
      - 'main'
      - 'releases/**'

注: branches フィルターと paths フィルターの両方を使用する� �合、ワークフローは両方のフィルターが満たされた� �合にのみ実行されます。 たとえば、次のワークフローは、JavaScript (.js) ファイルへの変更を含むプッシュが、名前が releases/ で始まるブランチに対して行われた� �合にのみ実行されます。

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

特定のタグのプッシュが発生した� �合にのみワークフローを実行する

tags または tags-ignore フィルターを使って、特定のタグがプッシュされたときにのみ実行するようにワークフローを構成できます。 詳細については、「GitHub Actions のワークフロー構文」を参照してく� さい。

たとえば、このワークフローは、v1. で始まるタグを誰かがプッシュしたときに実行されます。

on:
  push:
    tags:
      - v1.**

プッシュが特定のファイルに影響を与える� �合にのみワークフローを実行する

paths または paths-ignore フィルターを使って、特定のファイルへのプッシュが発生したときに実行するようにワークフローを構成することができます。 詳細については、「GitHub Actions のワークフロー構文」を参照してく� さい。

たとえば、このワークフローは、誰かが JavaScript ファイル (.js) に変更をプッシュしたときに実行されます。

on:
  push:
    paths:
      - '**.js'

注: branches フィルターと paths フィルターの両方を使用する� �合、ワークフローは両方のフィルターが満たされた� �合にのみ実行されます。 たとえば、次のワークフローは、JavaScript (.js) ファイルへの変更を含むプッシュが、名前が releases/ で始まるブランチに対して行われた� �合にのみ実行されます。

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

registry_package

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
registry_package- published
- updated
公開されたパッケージのコミット公開されたパッケージのブランチもしくはタグ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

GitHub Packages に関連するアクティビティがリポジトリで発生したときにワークフローを実行します。 詳細については、「GitHub Packages のドキュメント」を参照してく� さい。

たとえば、新しいパッケージのバージョンが published になったらワークフローを実行できます。

on:
  registry_package:
    types: [published]

release

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
release- published
- unpublished
- created
- edited
- deleted
- prereleased
- released
リリースのタグが付いた直近のコミットリリース refs/tags/<tag_name> のタグ参照

: このイベントは、2つ以上の種類のアクティビティで起動されます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: ワークフローは、ドラフト リリースのアクティビティの種類 creatededited、または deleted ではトリガーされません。 GitHub Enterprise Server ブラウザー UI を使ってリリースを作成すると、リリースがドラフトとして自動的に保存される� �合があります。

注: prereleased 型は、ドラフト リリースから公開されたプレリリースではトリガーされませんが、published 型はトリガーされます。 安定した プレリリースの発行時にワークフローを実行する� �合は、次のpublished代わりにサブスクライブreleasedしますprereleased

リポジトリのリリース アクティビティが発生したときにワークフローを実行します。 リリース API については、GraphQL API ドキュメントの「Release」または REST API ドキュメントの「リリース」を参照してく� さい。

たとえば、リリースが published � ったときにワークフローを実行できます。

on:
  release:
    types: [published]

repository_dispatch

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
repository_dispatchCustomデフォルトブランチの直近のコミットデフォルトブランチ

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

GitHub Enterprise Server の外部で生じるアクティビティのためにワークフローをトリガーしたい� �合、GitHub Enterprise Server API を使って、repository_dispatch と呼ばれる Webhook イベントをトリガーできます。 詳細については、「リポジトリ ディスパッチ イベントの作成」を参照してく� さい。

repository_dispatch イベントを作成する要求を行う� �合は、アクティビティの種類を説明する event_type を指定する必要があります。 既定では、repository_dispatch のすべてのアクティビティの種類によってワークフローの実行がトリガーされます。 types キーワードを使うと、repository_dispatch Webhook ペイロードで特定の event_type 値が送信されたときに実行されるワークフローを制限できます。

on:
  repository_dispatch:
    types: [on-demand-test]

注: event_type の値は 100 文字に制限されています。

client_payload パラメーターを使って送信するすべてのデータは、ワークフローの github.event コンテキストで使用できます。 たとえば、リポジトリ ディスパッチ イベントを作成するときにこの要求本文を送信する� �合は、次のようになります。

{
  "event_type": "test_result",
  "client_payload": {
    "passed": false,
    "message": "Error: timeout"
  }
}

その後、次のようにワークフロー内のペイロードにアクセスできます。

on:
  repository_dispatch:
    types: [test_result]

jobs:
  run_if_failure:
    if: ${{ !github.event.client_payload.passed }}
    runs-on: ubuntu-latest
    steps:
      - env:
          MESSAGE: ${{ github.event.client_payload.message }}
        run: echo $MESSAGE

schedule

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
該当なし該当なしデフォルトブランチの直近のコミットデフォルトブランチ

注: GitHub Actions のワークフローの実行によって高い� 荷がかかっている間、schedule イベントが遅延する可能性があります。 高� 荷の時間帯には、毎時の開始時点が含まれます。 遅延の可能性を減らすために、� 時間の中の別の時間帯に実行されるようワークフローをスケジューリングしてく� さい。

schedule イベントを使うと、スケジュールした時刻にワークフローをトリガーできます。

ワークフローを特定の UTC 時刻に実行するように、POSIX cron 構文でスケジュールすることができます。 スケジュールしたワークフローは、デフォルトまたはベースブランチの直近のコミットで実行されます。 スケジュールされたワークフローを実行できる最短の間隔は、5 分ごとに 1 回です。

この例では、ワークフローは毎日UTCの5:30と17:30にトリガーされます。

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '30 5,17 * * *'

1 つのワークフローを、複数の schedule イベントでトリガーできます。 github.event.schedule のコンテキストを使用して、ワークフローをトリガーしたスケジュール イベントにアクセスできます。 この例では、毎週月曜日から木曜日の 5 時 30 分 (UTC) にワークフローが実行されますが、月曜日と水曜日の Not on Monday or Wednesday 手� �はスキップされます。

on:
  schedule:
    - cron: '30 5 * * 1,3'
    - cron: '30 5 * * 2,4'

jobs:
  test_schedule:
    runs-on: ubuntu-latest
    steps:
      - name: Not on Monday or Wednesday
        if: github.event.schedule != '30 5 * * 1,3'
        run: echo "This step will be skipped on Monday and Wednesday"
      - name: Every time
        run: echo "This step will always run"

クーロン構文では、スペースで分けられた 5 つのフィールドがあり、各フィールドは時間の単位を表わします。

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *

5 つのフィールドいずれにおいても、以下の演算子を使用できます:

演算子説明
*任意の値15 * * * * では、毎日、毎時、15 分ごとに実行します。
,値リストの区切り文字2,10 4,5 * * * では、毎日、午前 4 時および 5 時の、2 分および 10 分に実行します。
-値の範囲30 4-6 * * * では、午前 4 時、5 時、6 時の、30 分に実行します。
/ステップ値20/15 * * * * では、20 分から 59 分までの間で、15 分おきに実行します (20 分、35 分、50 分)。

注: GitHub Actions では、標準以外の構文 @yearly@monthly@weekly@daily@hourly@reboot はサポートされません。

crontab guru を使うと、cron 構文の生成および実行時間の確認に役立ちます。 作業の開始に役立つ crontab guru のサンプル一覧もあります。

ワークフロー内のクーロン構文を最後に修正したユーザには、スケジュールされたワークフローの通知が送られます。 詳細については、「ワークフロー実行の通知」を参照してく� さい。

status

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
status該当なしデフォルトブランチの直近のコミット該当なし

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

Git コミットの状態が変更されたときにワークフローを実行します。 たとえば、コミットは errorfailurepending、または success としてマークできます。 状態の変更に関する詳細を指定する� �合は、check_run イベントを使用できます。 コミット状態 API については、GraphQL API ドキュメントの「Status」または REST API ドキュメントの状態に関するトピックを参照してく� さい。

たとえば、status イベントが発生したときにワークフローを実行できます。

on:
  status

新しいコミット状態に基づいてワークフローでジョブを実行する� �合は、github.event.state コンテキストを使用できます。 たとえば、次のワークフローはコミット状態が変更されたときにトリガーされますが、if_error_or_failure ジョブは新しいコミット状態が error または failure の� �合にのみ実行されます。

on:
  status
jobs:
  if_error_or_failure:
    runs-on: ubuntu-latest
    if: >-
      github.event.state == 'error' ||
      github.event.state == 'failure'
    steps:
      - env:
          DESCRIPTION: ${{ github.event.description }}
        run: |
          echo The status is error or failed: $DESCRIPTION

watch

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
watch- startedデフォルトブランチの直近のコミットデフォルトブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 アクティビティの種類 started のみがサポートされていますが、このアクティビティの種類を指定すると、今後さらにアクティビティの種類が追� された� �合に、ワークフローを特定のもののままにできます。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

ワークフローのリポジトリが Star 付きになったときにワークフローを実行します。 pull request API については、GraphQL API ドキュメントの「addStar」または REST API ドキュメントの Star 付けに関するトピックを参照してく� さい。

たとえば、誰かがリポジトリに star を付けたときにワークフローを実行できます。これは、Watch イベントのアクティビティの種類 started です。

on:
  watch:
    types: [started]

workflow_dispatch

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
workflow_dispatch該当なしGITHUB_REF ブランチでの最後のコミットディスパッチを受信したブランチ

ワークフローを手動でトリガーするには、workflow_dispatch イベントを使います。 GitHub Enterprise Server API、GitHub CLI、または GitHub Enterprise Server ブラウザー インターフェイスを使って、ワークフロー実行を手動でトリガーできます。 詳細については、「ワークフローの手動実行」を参照してく� さい。

on: workflow_dispatch

入力の提供

カスタ� 定義の入力プロパティ、デフォルトの入力値、イベントに必要な入力をワークフローで直接設定できます。 イベントをトリガーするときは、ref と任意の inputs を指定できます。 ワークフローが実行されたら、github.event.inputs コンテキストで入力値にアクセスできます。 詳細については、「コンテキスト」を参照してく� さい。

この例では、namehome の入力を定義し、github.event.inputs.namegithub.event.inputs.home のコンテキストを使ってそれらを出力します。 home が指定されていない� �合、既定値の 'The Octoverse' が出力されます。

name: Manually triggered workflow
on:
  workflow_dispatch:
    inputs:
      name:
        description: 'Person to greet'
        required: true
        default: 'Mona the Octocat'
      home:
        description: 'location'
        required: false
        default: 'The Octoverse'

jobs:
  say_hello:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo Hello $NAME!
          echo -in $HOME
        env:
          NAME: ${{ github.event.inputs.name }}
          HOME: ${{ github.event.inputs.home }}

workflow_run

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
workflow_run- completed
- requested
デフォルトブランチの直近のコミットデフォルトブランチ

: このイベントは、2つ以上の種類のアクティビティで起動されます。 ワークフローの再実行時にアクティビティの種類 requested は発生しません。 それぞれのアクティビティの種類については、「Webhook イベントとペイロード」を参照してく� さい。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。 types キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。

注: このイベントは、ワークフローファイルがデフォルト ブランチにある� �合にのみワークフローの実行をトリガーします。

注: 3 つを超えるレベルのワークフローを連結するために、workflow_run を使うことはできません。 たとえば、最初のワークフロー A の実行後に (B から F という) 5 つのワークフローをトリガーして� �番に実行しようとした� �合 (つまり、ABCDEF)、ワークフロー EF は実行されません。

このイベントは、ワークフローの実行が要求されたか完了したときに発生します。 これで、別のワークフローの実行または完了に基づいてワークフローを実行できます。 workflow_run イベントによって開始されたワークフローでは、前のワークフローではできなかった� �合でも、シークレットや書き込みトークンにアクセスできます。 これは、以前のワークフローが意図的に権限を与えられていない� �合に役立ちますが、権限を与えられたアクションは後のワークフローで行わなければなりません。

この例では、ワークフローは個別の「Run Tests」ワークフローの完了後に実行されるように設定されています。

on:
  workflow_run:
    workflows: [Run Tests]
    types:
      - completed

workflow_run イベントに複数の workflows を指定した� �合、実行する必要があるワークフローは 1 つ� けです。 たとえば、次のトリガーを持つワークフローは、"ステージング" ワークフローまたは "ラボ" ワークフローが完了するたびに実行されます。

on:
  workflow_run:
    workflows: [Staging, Lab]
    types:
      - completed

別のワークフローの結果に基づいてワークフローを実行する

ワークフロー実行は、前のワークフローの結果に関係なくトリガーされます。 トリガーするワークフローの結果に基づいてジョブまたはステップを実行する� �合は、github.event.workflow_run.conclusion プロパティで条件を使用できます。 たとえば、このワークフローは、"Build" という名前のワークフローが完了するたびに実行されますが、on-success ジョブは、"Build" ワークフローが成功した� �合にのみ実行され、on-failure ジョブは "Build" ワークフローが失敗した� �合にのみ実行されます。

on:
  workflow_run:
    workflows: [Build]
    types: [completed]

jobs:
  on-success:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - run: echo 'The triggering workflow passed'
  on-failure:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    steps:
      - run: echo 'The triggering workflow failed'

ブランチに基づいて実行するワークフローを制限する

branches または branches-ignore フィルターを使って、ワークフローをトリガーするために、トリガーするワークフローで実行する必要があるブランチを指定できます。 詳細については、「GitHub Actions のワークフロー構文」を参照してく� さい。 たとえば、次のトリガーを持つワークフローは、名前が canary のブランチで Build という名前のワークフローが実行される� �合にのみ実行されます。

on:
  workflow_run:
    workflows: [Build]
    types: [requested]
    branches: [canary]

トリガーするワークフローからデータを使う

ワークフローをトリガーしたワークフローに対応する workflow_runイベント ペイロードにアクセスできます。 たとえば、トリガーするワークフローによって成果物が生成される� �合、workflow_run イベントでトリガーされたワークフローからこれらの成果物にアクセスできます。

次のワークフローでは、データを成果物としてアップロードします。 (この簡略化された例では、データは pull request 番号です)。

name: Upload data

on:
  pull_request:

jobs:
  upload:
    runs-on: ubuntu-latest

    steps:
      - name: Save PR number
        env:
          PR_NUMBER: ${{ github.event.number }}
        run: |
          mkdir -p ./pr
          echo $PR_NUMBER > ./pr/pr_number
      - uses: actions/upload-artifact@v2
        with:
          name: pr_number
          path: pr/

上記のワークフローの実行が完了すると、次のワークフローの実行がトリガーされます。 次のワークフローでは、github.event.workflow_run コンテキストと GitHub Enterprise Server REST API を使って、上記のワークフローによってアップロードされた成果物をダウンロードします。また、ダウンロードした成果物を解凍し、番号が成果物としてアップロードされた pull request についてコメントします。

name: Use the data

on:
  workflow_run:
    workflows: [Upload data]
    types:
      - completed

jobs:
  download:
    runs-on: ubuntu-latest
    steps:
      - name: 'Download artifact'
        uses: actions/github-script@v5
        with:
          script: |
            let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
               owner: context.repo.owner,
               repo: context.repo.repo,
               run_id: context.payload.workflow_run.id,
            });
            let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
              return artifact.name == "pr_number"
            })[0];
            let download = await github.rest.actions.downloadArtifact({
               owner: context.repo.owner,
               repo: context.repo.repo,
               artifact_id: matchArtifact.id,
               archive_format: 'zip',
            });
            let fs = require('fs');
            fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/pr_number.zip`, Buffer.from(download.data));

      - name: 'Unzip artifact'
        run: unzip pr_number.zip

      - name: 'Comment on PR'
        uses: actions/github-script@v5
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            let fs = require('fs');
            let issue_number = Number(fs.readFileSync('./pr_number'));
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: issue_number,
              body: 'Thank you for the PR!'
            });