Skip to main content

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

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

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

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

イベントによっては、複数のアクティビティの種類があります。 このようなイベントでは、ワークフローの実行をトリガーするアクティビティの種類を指定できます。 各アクティビティの種類の意味について詳しくは、「Webhook のイベントとペイロード」をご覧ください。

注: すべての Webhook イベントがワークフローをトリガーするわけではありません。

branch_protection_rule

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

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

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

ワークフロー リポジトリ内のブランチ保護ルールが変更されたときにワークフローを実行します。 ブランチ保護ルールについて詳しくは、「保護されたブランチについて」をご覧ください。 ブランチ保護ルール API については、GraphQL API ドキュメントの「オブジェクト」または「ブランチとその設定用 REST API エンドポイント」をご覧ください。

たとえば、ブランチ保護ルールが created または deleted だったときにワークフローを実行できます。

on:
  branch_protection_rule:
    types: [created, deleted]

check_run

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

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

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

チェック実行に関連するアクティビティが発生したときにワークフローを実行します。 チェックの実行は、個別のテストであり、チェックスイートの一機能です。 詳しくは、「REST API を使用してチェックを操作する」をご覧ください。 チェック実行 API については、GraphQL API ドキュメントの「オブジェクト」または「チェック実行用 REST API エンドポイント」をご覧ください。

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

on:
  check_run:
    types: [rerequested, completed]

check_suite

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

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

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

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

チェック スイートのアクティビティが発生したときにワークフローを実行します。 チェック スイートは、特定のコミットに対して作成されたチェック実行のコレクションです。 チェック スイートでは、スイート内のチェック実行の状態と結果をまとめます。 詳しくは、「REST API を使用してチェックを操作する」をご覧ください。 チェック スイート API については、GraphQL API ドキュメントの「オブジェクト」または「チェック スイート用 REST API エンドポイント」をご覧ください。

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

on:
  check_suite:
    types: [completed]

create

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

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

誰かがワークフローのリポジトリに Git 参照 (Git ブランチまたはタグ) を作成したときにワークフローを実行します。 Git 参照を作成するための API については、GraphQL API ドキュメントの「ミューテーション」または「Git リファレンス用 REST API エンドポイント」をご覧ください。

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

on:
  create

delete

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

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

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

誰かがワークフローのリポジトリで Git 参照 (Git ブランチまたはタグ) を削除したときにワークフローを実行します。 Git 参照を削除するための API については、GraphQL API ドキュメントの「ミューテーション」または「Git リファレンス用 REST API エンドポイント」をご覧ください。

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

on:
  delete

deployment

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

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

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

on:
  deployment

deployment_status

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

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

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

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

on:
  deployment_status

discussion

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
discussion- created
- edited
- deleted
- transferred
- pinned
- unpinned
- labeled
- unlabeled
- locked
- unlocked
- category_changed
- answered
- unanswered
デフォルトブランチの直近のコミットデフォルトブランチ

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

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

注: GitHub Discussions の Webhook イベントは現在ベータ版であり、変更される可能性があります。

ワークフローのリポジトリ内のディスカッションが作成または変更されたときにワークフローを実行します。 ディスカッションのコメントに関連するアクティビティには、discussion_comment イベントを使います。 ディスカッションについて詳しくは、「ディスカッションについて」をご覧ください。 GraphQL API については、「オブジェクト」をご覧ください。

たとえば、ディスカッションが creatededited、または answered だったときにワークフローを実行できます。

on:
  discussion:
    types: [created, edited, answered]

discussion_comment

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

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

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

注: GitHub Discussions の Webhook イベントは現在ベータ版であり、変更される可能性があります。

ワークフローのリポジトリ内のディスカッションのコメントが作成または変更されたときにワークフローを実行します。 ディスカッションのコメントではなくディスカッションに関連するアクティビティには、discussion イベントを使います。 ディスカッションについて詳しくは、「ディスカッションについて」をご覧ください。 GraphQL API については、「オブジェクト」をご覧ください。

たとえば、ディスカッション コメントが created または deleted だったときにワークフローを実行できます。

on:
  discussion_comment:
    types: [created, deleted]

fork

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

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

誰かがリポジトリをフォークしたときにワークフローを実行します。 REST API については、「フォーク用の REST API エンドポイント」をご覧ください。

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

on:
  fork

gollum

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

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

誰かが Wiki ページを作成または更新したときにワークフローを実行します。 詳しくは、「ウィキについて」を参照してください。

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

on:
  gollum

issue_comment

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

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

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

issue または pull request のコメントが作成、編集、または削除されたときにワークフローを実行します。 issue コメント API については、GraphQL API ドキュメントの「オブジェクト」または REST API ドキュメントの「Webhook のイベントとペイロード」をご覧ください。

たとえば、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 キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。

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

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

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

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

label

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

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

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

ワークフローのリポジトリ内のラベルが作成または変更されたときにワークフローを実行します。 ラベルについて詳しくは、「ラベルを管理する」をご覧ください。 ラベル API については、GraphQL API ドキュメントの「オブジェクト」または「ラベル用の REST API エンドポイント」をご覧ください。

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

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

on:
  label:
    types: [created, deleted]

merge_group

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
merge_groupchecks_requestedマージ グループの SHAマージ グループの ref

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

マージ キューに pull request が追加されたときにワークフローを実行し、マージ グループにその pull request を追加します。 詳しくは、「pull request とマージ キューのマージ」をご覧ください。

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

on:
  merge_group:
    types: [checks_requested]

milestone

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

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

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

ワークフローのリポジトリ内のマイルストーンが作成または変更されたときにワークフローを実行します。 マイルストーンについて詳しくは、「マイルストーンについて」をご覧ください。 マイルストーン API については、GraphQL API ドキュメントの「オブジェクト」または「マイルストーン用の 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 については、「リポジトリの REST API エンドポイント」をご覧ください。

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

on:
  page_build

project

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

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

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

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

: このイベントは、projects (classic) に対してのみ発生します。

プロジェクト (クラシック)が作成または変更されたときにワークフローを実行します。 プロジェクト (クラシック)のカードまたは列に関連するアクティビティには、代わりに project_card または project_column イベントを使用します。 プロジェクト (クラシック)の詳細については、「projects (classic)について」を参照してください。 プロジェクト (クラシック) API の詳細については、GraphQL API ドキュメントの「オブジェクト」または「Projects (classic)用 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 キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。

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

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

: このイベントは、projects (classic) に対してのみ発生します。

プロジェクト (クラシック)のカードが作成または変更されたときにワークフローを実行します。 プロジェクト (クラシック) または プロジェクト (クラシック)の列に関連するアクティビティのには、代わりに project または project_column イベントを使用します。 プロジェクト (クラシック)の詳細については、「projects (classic)について」を参照してください。 プロジェクト カード API の詳細については、GraphQL API ドキュメントの「オブジェクト」または「Project (classic)カード用 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 キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。

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

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

: このイベントは、projects (classic) に対してのみ発生します。

プロジェクト (クラシック)の列が作成または変更されたときにワークフローを実行します。 プロジェクト (クラシック) または プロジェクト (クラシック) のカードに関連するアクティビティには、代わりに project または project_card イベントを使用します。 プロジェクト (クラシック)の詳細については、「projects (classic)について」を参照してください。 プロジェクト列 API の詳細については、GraphQL API ドキュメントの「オブジェクト」または「Projects (classic)用 REST API エンドポイント」をご覧ください。

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

on:
  project_column:
    types: [created, deleted]

public

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

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

ワークフローのリポジトリがプライベートからパブリックに変更されたときにワークフローを実行します。 REST API については、「リポジトリの 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
- locked
- unlocked
- enqueued
- dequeued
- milestoned
- demilestoned
- ready_for_review
- review_requested
- review_request_removed
- auto_merge_enabled
- auto_merge_disabled
GITHUB_REF ブランチでの最後のマージ コミットPR マージ ブランチ refs/pull/PULL_REQUEST_NUMBER/merge

注:

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

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

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

  • pull_request webhook イベント ペイロードは、マージされた pull request とフォークされたリポジトリから取得された pull request に対して空です。

  • GITHUB_REF の値は、pull request がマージされたかどうかによって、クローズされたプル要求の場合は異なります。 pull request はクローズされたが、マージされていない場合は refs/pull/PULL_REQUEST_NUMBER/merge になります。 マージの結果として pull request がクローズされた場合は、マージ先のブランチの完全修飾 ref (/refs/heads/main など) になります。

ワークフローのリポジトリ内の 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 ドキュメントの「オブジェクト」または「Pull request 用 REST API エンドポイント」をご覧ください。

このイベントの 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 またはベース ブランチに基づいて pull_request ワークフローを実行する

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

たとえば、このワークフローは、名前が 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 ワークフローを実行する

また、pull request によって特定のファイルが変更されたときに実行するようにワークフローを構成することもできます。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。

たとえば、このワークフローは、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 は自動的に閉じられます。 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 には、フォークされたリポジトリからの pull request での読み取り専用アクセス許可があります。 詳しくは、「自動トークン認証」を参照してください。

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

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

初めてのコントリビューターがパブリックリポジトリに pull request をサブミットした場合、書き込み権限を持つメンテナがその pull request に対するワークフローの実行を承認しなければならないことがあります。 詳しくは、「パブリックフォークで実行されるワークフローの実行を承認する」を参照してください。

フォークされたリポジトリからプライベート リポジトリへの pull request の場合、ワークフローは有効になっている場合にのみ実行されます。「リポジトリの GitHub Actions の設定を管理する」を参照してください。

注: 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/PULL_REQUEST_NUMBER/merge

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

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

たとえば、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 には、フォークされたリポジトリからの pull request での読み取り専用アクセス許可があります。 詳しくは、「自動トークン認証」を参照してください。

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

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

初めてのコントリビューターがパブリックリポジトリに pull request をサブミットした場合、書き込み権限を持つメンテナがその pull request に対するワークフローの実行を承認しなければならないことがあります。 詳しくは、「パブリックフォークで実行されるワークフローの実行を承認する」を参照してください。

フォークされたリポジトリからプライベート リポジトリへの pull request の場合、ワークフローは有効になっている場合にのみ実行されます。「リポジトリの GitHub Actions の設定を管理する」を参照してください。

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

pull_request_review_comment

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

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

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

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

on:
  pull_request_review_comment:
    types: [created, deleted]

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

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

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

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

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

初めてのコントリビューターがパブリックリポジトリに pull request をサブミットした場合、書き込み権限を持つメンテナがその pull request に対するワークフローの実行を承認しなければならないことがあります。 詳しくは、「パブリックフォークで実行されるワークフローの実行を承認する」を参照してください。

フォークされたリポジトリからプライベート リポジトリへの pull request の場合、ワークフローは有効になっている場合にのみ実行されます。「リポジトリの GitHub Actions の設定を管理する」を参照してください。

注: 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 キーワードを使います。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。

ワークフローのリポジトリ内の 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 またはベース ブランチに基づいて pull_request_target ワークフローを実行する

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

たとえば、このワークフローは、名前が 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_target:
    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_target ワークフローを実行する

paths または paths-ignore フィルターを使って、pull request によって特定のファイルが変更されたときに実行するようにワークフローを構成することもできます。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。

たとえば、このワークフローは、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_target ワークフローを実行する

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 のドキュメントの「オブジェクト」または「コミット用の REST API エンドポイント」をご覧ください。

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

コミットまたはタグをプッシュするとき、またはテンプレートからリポジトリを作成するときにワークフローを実行します。

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

on:
  push

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

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

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

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

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

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

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

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

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

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

on:
  push:
    tags:
      - v1.**

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

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

たとえば、このワークフローは、誰かが 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 キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。

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

: マルチアーキテクチャ コンテナー イメージをプッシュする場合、このイベントはマニフェストごとに 1 回発生するため、ワークフローが複数回トリガーされることがあります。 これを軽減し、実際のイメージ タグ情報を含むイベントに対してのみワークフロー ジョブを実行するには、条件を使用します。

jobs:
    job_name:
        if: ${{ github.event.registry_package.package_version.container_metadata.tag.name != '' }}

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 キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。

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

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

リポジトリのリリース アクティビティが発生したときにワークフローを実行します。 リリース API については、GraphQL API ドキュメントの「オブジェクト」または REST API ドキュメントの「リリースとリリース資産の REST API エンドポイント」をご覧ください。

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

on:
  release:
    types: [published]

repository_dispatch

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

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

GitHub の外部で生じるアクティビティのためにワークフローをトリガーしたい場合、GitHub API を使って、repository_dispatch と呼ばれる Webhook イベントをトリガーできます。 詳しくは、「リポジトリの REST API エンドポイント」を参照してください。

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

on:
  repository_dispatch:
    types: [test_result]

注: 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

:

  • client_payload の最上位レベルのプロパティの最大数は 10 です。
  • ペイロードには、最大 65,535 文字を含めることができます。

schedule

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

注:

  • GitHub Actions のワークフローの実行によって高い負荷がかかっている間、schedule イベントが遅延する可能性があります。 高負荷の時間帯には、毎時の開始時点が含まれます。 負荷が十分に高い場合、キューに登録されたジョブの一部が削除される可能性があります。 遅延の可能性を減らすために、Ⅰ時間の中の別の時間帯に実行されるようワークフローをスケジューリングしてください。
  • パブリックリポジトリでは、60日間にリポジトリにアクティビティがなかった場合、スケジュールされたワークフローは自動的に無効化されます。 無効になったワークフローを再度有効にするための詳細については、「ワークフローの無効化と有効化」を参照してください。
  • スケジュールされたワークフローにコミットする最後のユーザーが組織から削除されると、スケジュールされたワークフローは無効になります。 リポジトリへの write アクセス許可を持つユーザーがスケジュールされたワークフロー ファイルにコミットすると、スケジュールされたワークフローが再アクティブ化されます。

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 つのフィールドいずれにおいても、以下の演算子を使用できます:

演算子Description
*任意の値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 ドキュメントの「オブジェクト」または「コミット用の 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 キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。

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

ワークフローのリポジトリが Star 付きになったときにワークフローを実行します。 pull request API については、GraphQL API ドキュメントの「ミューテーション」または「星付け用 REST API エンドポイント」をご覧ください。

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

on:
  watch:
    types: [started]

workflow_call

webhook イベントのペイロードアクティビティの種類GITHUB_SHAGITHUB_REF
呼び出し元ワークフローと同じ該当なし呼び出し元ワークフローと同じ呼び出し元ワークフローと同じ

workflow_call は、別のワークフローからワークフローを呼び出すことができることを示すために使用されます。 workflow_call イベントを使ってワークフローがトリガーされると、呼び出し対象のワークフロー内のイベント ペイロードは、呼び出し元ワークフローからの同じイベント ペイロードになります。 詳しくは、「ワークフローの再利用」をご覧ください。

次の例では、別のワークフローから呼び出された場合にのみワークフローを実行します。

on: workflow_call

workflow_dispatch

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

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

ワークフローを手動でトリガーできるようにするには、workflow_dispatch イベントを構成する必要があります。 GitHub API、GitHub CLI、または GitHub ブラウザー インターフェイスを使って、ワークフロー実行を手動でトリガーできます。 詳しくは、「ワークフローの手動実行」を参照してください。

on: workflow_dispatch

入力の提供

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

:

  • ワークフローは、github.event.inputs コンテキスト内の入力も受け取ります。 inputs コンテキストと github.event.inputs コンテキストの情報ですが、inputs コンテキストではブール値が文字列に変換されず、ブール値として保持されます。 choice 型は文字列に解決され、1 つの選択可能なオプションです。
  • inputs の最上位レベルのプロパティの最大数は 10 です。
  • inputs のペイロードの最大数は 65,535 文字です。

この例では、logLeveltagsenvironment という名前の入力が定義されています。 これらの入力の値は、ワークフローに実行時に渡します。 その後、このワークフローで、inputs.logLevelinputs.tagsinputs.environment コンテキスト プロパティを使って、値をログに出力します。

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
        - info
        - warning
        - debug
      tags:
        description: 'Test scenario tags'
        required: false
        type: boolean
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true

jobs:
  log-the-inputs:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Log level: $LEVEL"
          echo "Tags: $TAGS"
          echo "Environment: $ENVIRONMENT"
        env:
          LEVEL: ${{ inputs.logLevel }}
          TAGS: ${{ inputs.tags }}
          ENVIRONMENT: ${{ inputs.environment }}

ブラウザーからこのワークフローを実行する場合は、ワークフローを実行する前に、必要な入力の値を手動で入力する必要があります。

ワークフロー実行一覧のスクリーンショット。 "ワークフローの実行" というラベルが付き、入力フィールドを表示するように展開されたドロップダウン メニューが、濃いオレンジ色の枠線で囲まれています。

スクリプトからワークフローを実行するとき、または GitHub CLI を使って、入力を渡すこともできます。 次に例を示します。

gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging

詳しくは、「ワークフローの手動実行」で GitHub CLI の情報をご覧ください。

workflow_run

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

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

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

注: 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 フィルターを使って、ワークフローをトリガーするために、トリガーするワークフローで実行する必要があるブランチを指定できます。 詳しくは、「ギットハブ アクション のワークフロー構文」を参照してください。 たとえば、次のトリガーを持つワークフローは、名前が 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@v4
        with:
          name: pr_number
          path: pr/

上記のワークフローの実行が完了すると、次のワークフローの実行がトリガーされます。 次のワークフローでは、github.event.workflow_run コンテキストと GitHub 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@v6
        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@v6
        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!'
            });