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

ワークフローイベントを設定する

on ワークフロー構文を使用して、1 つ以上のイベントに対して実行するようにワークフローを設定できます。 詳しい情報については、「GitHub Actions のワークフロー構文」を参照してください。

単一のイベントを使用する例

# リポジトリ内の任意のブランチにコードがプッシュされたときにトリガーされる
on: push

イベントのリストを使用する例

# プッシュもしくはPull Requestイベントでワークフローをトリガーする
on: [push, pull_request]

アクティビティの種類もしくは設定を伴う複数のイベントを使用する例

イベントに対してアクティビティの種類もしくは設定を指定する必要がある場合、それぞれのイベントを個別に設定しなければなりません。 設定を持たないイベントも含め、すべてのイベントにはコロン (:)を追加しなければなりません。

on:
  # プッシュもしくはPull Requestでワークフローをトリガーする
  # ただしメインブランチの場合のみ
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # page_buildとリリース作成イベントでもトリガーする
  page_build:
  release:
    types: # この設定は上記のpage_buildイベントには影響しない
      - created

ワークフローの実行がトリガーされるには、以下のステップが生じます。

1. リポジトリでイベントが発生し、結果のイベントにはコミット SHA と Git ref が関連付けられます。

2. リポジトリ内の関連づけられたコミットSHAもしくはGit refにおける .github/workflowsディレクトリ内でワークフローファイルが検索される。 ワークフローファイルは、コミットSHAあるいはGit refを考慮した上で存在していなければなりません。

   たとえば、イベントが特定のリポジトリブランチで発生したなら、ワークフローファイルはそのブランチ上でリポジトリ内に存在しなければなりません。

3. そのコミットSHA及びGit refのワークフローファイルが調べられ、トリガーを起こしたイベントにマッチするon:の値を持つワークフローについて新しい実行がトリガーされる。

   ワークフローの実行は、イベントをトリガーしたのと同じコミットSHA及びGit refにあるリポジトリのコード上で実行されます。 ワークフローを実行すると、GitHub Enterprise Server はランナー環境において GITHUB_SHA (コミット SHA) および GITHUB_REF (Git ref) 環境変数を設定します。 詳しい情報については、「環境変数の利用」を参照してください。

スケジュールしたイベント

schedule イベントを使用すると、スケジュールされた時間にワークフローをトリガーできます。

スケジュール

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
n/a	n/a	デフォルトブランチの直近のコミット	デフォルトブランチ

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

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

on:
  schedule:
    # *はYAMLにおける特殊文字なので、この文字列はクオートしなければならない
    - cron:  '30 5,17 * * *'

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

┌───────────── 分 (0 - 59)
│ ┌───────────── 時間 (0 - 23)
│ │ ┌───────────── 日 (1 - 31)
│ │ │ ┌───────────── 月 (1 - 12 または JAN-DEC)
│ │ │ │ ┌───────────── 曜日 (0 - 6 または SUN-SAT)
│ │ │ │ │                                   
│ │ │ │ │
│ │ │ │ │
* * * * *

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

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

crontab guru を使うと、クーロン構文の生成および実行時間の確認に役立ちます。 また、クーロン構文の生成を支援するため、crontab guru のサンプルリストもあります。

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

手動イベント

ワークフローの実行を手動でトリガーできます。 リポジトリ内の特定のワークフローをトリガーするには、workflow_dispatch イベントを使用します。 リポジトリで複数のワークフローをトリガーし、カスタムイベントとイベントタイプを作成するには、repository_dispatch イベントを使用します。

workflow_dispatch

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
workflow_dispatch	n/a	GITHUB_REF ブランチ上の直近のコミット	ディスパッチを受信したブランチ

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

You can manually trigger a workflow run using the GitHub API and from GitHub. 詳しい情報については、「ワークフローを手動で実行する」を参照してください。

GitHub でイベントをトリガーすると、GitHub で ref と inputs を直接入力できます。 詳しい情報については、「アクションで入力と出力を使用する」を参照してください。

REST API を使用してカスタム workflow_dispatch webhook イベントをトリガーするには、POST リクエストを GitHub API エンドポイントに送信し、ref および必要な inputs を入力する必要があります。 詳細については、「ワークフローディスパッチイベントの作成」REST API エンドポイントを参照してください。

サンプル

workflow_dispatchイベントを使うには、GitHub Actionsのワークフローファイル中にトリガーとして含めなければなりません。 以下の例では、手動でトリガーされた場合にのみワークフローが実行されます。

on: workflow_dispatch

ワークフロー設定の例

この例では、 nameとhomeの入力を定義し、github.event.inputs.nameおよびgithub.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 ${{ github.event.inputs.name }}!"
          echo "- in ${{ github.event.inputs.home }}!"

repository_dispatch

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
repository_dispatch	n/a	デフォルトブランチの直近のコミット	デフォルトブランチ

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

カスタム repository_dispatch webhook イベントをトリガーするには、GitHub Enterprise Server API エンドポイントに POST リクエストを送信して、アクティビティのタイプを説明する event_type 名を提供する必要があります。 ワークフローの実行をトリガーするには、repository_dispatch イベントを使用するようワークフローを設定する必要もあります。

サンプル

デフォルトでは、すべてのevent_typesがワークフローの実行をトリガーします。 特定のevent_typeの値がrepository_dispatch webhookのペイロード内で送信された時にのみワークフローが実行されるように制限できます。 リポジトリのディスパッチイベントを生成する際に、repository_dispatchペイロード内で送信されるイベントの種類を定義します。

on:
  repository_dispatch:
    types: [opened, deleted]

webhook イベント

webhook イベントが GitHub Enterprise Server で生成されたときに実行されるようにワークフローを設定できます イベントによっては、そのイベントをトリガーするアクティビティタイプが 複数あります。 イベントをトリガーするアクティビティタイプが複数ある場合は、ワークフローの実行をトリガーするアクティビティタイプを指定できます。 詳しい情報については、「webhook」を参照してください。

すべての webhook イベントがワークフローをトリガーするわけではありません。 使用可能な webhook イベントとそのペイロードの完全なリストについては、「webhook イベントとペイロード」を参照してください。

check_run

check_run イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「チェック実行」を参照してください。

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

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

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

on:
  check_run:
    types: [rerequested, completed]

check_suite

check_suite イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「チェックスイート」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
check_suite	- completed - requested - rerequested	デフォルトブランチの直近のコミット	デフォルトブランチ

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

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

on:
  check_suite:
    types: [rerequested, completed]

create

誰かがブランチまたはタグを作成し、それによって create イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「リファレンスの作成」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
create	n/a	直近でブランチまたはタグが作成されたコミット	作成されたブランチまたはタグ

たとえば、create イベントが発生したときにワークフローを実行する例は、次のとおりです。

on:
  create

delete

誰かがブランチまたはタグを作成し、それによって delete イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「リファレンスの削除」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
delete	n/a	デフォルトブランチの直近のコミット	デフォルトブランチ

たとえば、delete イベントが発生したときにワークフローを実行する例は、次のとおりです。

on:
  delete

deployment

誰かがデプロイメントを作成し、それによって deployment イベントがトリガーされるときにワークフローを実行します。 コミット SHA 付きで作成されたデプロイメントには Git ref がない場合があります。 REST API の詳細については、「デプロイメント」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
deployment	n/a	デプロイされるコミット	デプロイされるブランチまたはタグ (コミットの場合は空)

たとえば、deployment イベントが発生したときにワークフローを実行する例は、次のとおりです。

on:
  deployment

deployment_status

サードパーティプロバイダーがデプロイメントステータスを提供し、それによって deployment_status イベントがトリガーされるときにワークフローを実行します。 コミット SHA 付きで作成されたデプロイメントには Git ref がない場合があります。 REST API の詳細については、「デプロイメントステータスの作成」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
deployment_status	n/a	デプロイされるコミット	デプロイされるブランチまたはタグ (コミットの場合は空)

たとえば、deployment_status イベントが発生したときにワークフローを実行する例は、次のとおりです。

on:
  deployment_status

フォーク

誰かがリポジトリをフォークし、それによって deployment_status イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「フォークの作成」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
フォーク	n/a	デフォルトブランチの直近のコミット	デフォルトブランチ

たとえば、fork イベントが発生したときにワークフローを実行する例は、次のとおりです。

on:
  fork

gollum

誰かが Wiki ページを作成または更新し、それによって gollum イベントがトリガーされるときにワークフローを実行します。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
gollum	n/a	デフォルトブランチの直近のコミット	デフォルトブランチ

たとえば、gollum イベントが発生したときにワークフローを実行する例は、次のとおりです。

on:
  gollum

issue_comment

issue_comment イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「Issue コメント」を参照してください。

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

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

たとえば、Issue コメントが created または deleted だったときにワークフローを実行する例は、次のとおりです。

on:
  issue_comment:
    types: [created, deleted]

issue_commentイベントは、IssueやPull Requestにコメントされたときに生じます。 issue_commentイベントがIssueで生じたのかPull Requestで生じたのかを判断するには、イベントのペイロードのissue.pull_request属性をチェックして、それをジョブをスキップする条件として利用できます。

たとえば、コメントイベントがPull Requestで生じたときにpr_commentedを実行し、コメントイベントがIssueで生じたときにissue_commentedジョブを実行するようにできます。

on: issue_comment

jobs:
  pr_commented:
    # このジョブはプルリクエストコメントに対してのみ実行されます
    name: PR comment
    if: ${{ github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Comment on PR #${{ github.event.issue.number }}"

  issue_commented:
    # このジョブは Issue comment に対してのみ実行されます
    name: Issue comment
    if: ${{ !github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Comment on issue #${{ github.event.issue.number }}"

issues

Issue イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「Issue」を参照してください。

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

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

たとえば、Issue が opened、edited、または milestoned だったときにワークフローを実行する例は、次のとおりです。

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

ラベル

label イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「ラベル」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
ラベル	- created - edited - deleted	デフォルトブランチの直近のコミット	デフォルトブランチ

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

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

on:
  label:
    types: [created, deleted]

マイルストーン

milestone イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「マイルストーン」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
マイルストーン	- created - closed - opened - edited - deleted	デフォルトブランチの直近のコミット	デフォルトブランチ

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

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

on:
  milestone:
    types: [opened, deleted]

page_build

誰かが GitHub Enterprise Server ページ対応のブランチを作成し、それによって page_build イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「ページ」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
page_build	n/a	デフォルトブランチの直近のコミット	n/a

たとえば、page_build イベントが発生したときにワークフローを実行する例は、次のとおりです。

on:
  page_build

project

project イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「プロジェクト」を参照してください。

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

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

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

on:
  project:
    types: [created, deleted]

project_card

project_card イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「プロジェクトカード」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
project_card	- created - moved - converted to an issue - edited - deleted	デフォルトブランチの直近のコミット	デフォルトブランチ

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

たとえば、プロジェクトカードが opened または deleted だったときにワークフローを実行する例は、次のとおりです。

on:
  project_card:
    types: [created, deleted]

project_column

project_column イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「プロジェクト列」を参照してください。

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

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

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

on:
  project_column:
    types: [created, deleted]

public

誰かがプライベートリポジトリをパブリックにし、それによって public イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「リポジトリの編集」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
public	n/a	デフォルトブランチの直近のコミット	デフォルトブランチ

たとえば、public イベントが発生したときにワークフローを実行する例は、次のとおりです。

on:
  public

pull_request

pull_request イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 For information about the REST API, see "Pull requests."

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_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	GITHUB_REF ブランチ上の直近のマージコミット	PR マージブランチ refs/pull/:prNumber/merge

デフォルトのアクティビティタイプを拡大または制限するには、types キーワードを使用します。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

たとえば、プルリクエストが assigned、opened、synchronize、または reopened だったときにワークフローを実行できます。

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

フォークしたリポジトリのPull Requestイベント

フォークされたリポジトリからベースリポジトリに対するPull Requestを作成した場合、GitHubはベースリポジトリに対してpull_requestイベントを送り、フォークされたリポジトリではPull Requestイベントは生じません。

デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 フォークされたリポジトリの ActionsタブでGitHub Actionsを有効化しなければなりません。

GITHUB_TOKENを除き、フォークしたリポジトリからワークフローがトリガーされた場合、シークレットはランナーに渡されません。 フォークされたリポジトリ内のGITHUB_TOKENの権限は読み取りのみです。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。

pull_request_review

pull_request_review イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 For information about the REST API, see "Pull request reviews."

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
pull_request_review	- submitted - edited - dismissed	GITHUB_REF ブランチ上の直近のマージコミット	PR マージブランチ refs/pull/:prNumber/merge

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

たとえば、プルリクエストレビューが edited または dismissed だったときにワークフローを実行する例は、次のとおりです。

on:
  pull_request_review:
    types: [edited, dismissed]

フォークしたリポジトリのPull Requestイベント

フォークされたリポジトリからベースリポジトリに対するPull Requestを作成した場合、GitHubはベースリポジトリに対してpull_requestイベントを送り、フォークされたリポジトリではPull Requestイベントは生じません。

デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 フォークされたリポジトリの ActionsタブでGitHub Actionsを有効化しなければなりません。

GITHUB_TOKENを除き、フォークしたリポジトリからワークフローがトリガーされた場合、シークレットはランナーに渡されません。 フォークされたリポジトリ内のGITHUB_TOKENの権限は読み取りのみです。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。

pull_request_review_comment

プルリクエストの統合 diff へのコメントが変更され、それによって pull_request_review_comment イベントがトリガーされるときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 For information about the REST API, see Review comments.

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
pull_request_review_comment	- created - edited - deleted	GITHUB_REF ブランチ上の直近のマージコミット	PR マージブランチ refs/pull/:prNumber/merge

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

たとえば、プルリクエストレビューコメントが created または deleted だったときにワークフローを実行する例は、次のとおりです。

on:
  pull_request_review_comment:
    types: [created, deleted]

フォークしたリポジトリのPull Requestイベント

フォークされたリポジトリからベースリポジトリに対するPull Requestを作成した場合、GitHubはベースリポジトリに対してpull_requestイベントを送り、フォークされたリポジトリではPull Requestイベントは生じません。

デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 フォークされたリポジトリの ActionsタブでGitHub Actionsを有効化しなければなりません。

GITHUB_TOKENを除き、フォークしたリポジトリからワークフローがトリガーされた場合、シークレットはランナーに渡されません。 フォークされたリポジトリ内のGITHUB_TOKENの権限は読み取りのみです。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。

プッシュ

誰かがリポジトリブランチにプッシュし、それによって push イベントがトリガーされるときにワークフローを実行します。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
プッシュ	n/a	プッシュされたコミット、ただし (デフォルトブランチの際に) ブランチを削除する場合を除く	更新された ref

たとえば、push イベントが発生したときにワークフローを実行する例は、次のとおりです。

on:
  push

registry_package

パッケージがpublishedもしくはupdatedされるとワークフローを実行します。 詳しい情報については「GitHub Packagesでのパッケージ管理」を参照してください。

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

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

たとえば、パッケージがpublishedされたときにワークフローを実行できます。

on:
  registry_package:
    types: [published]

リリース

release イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「リリース」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
リリース	- published - unpublished - created - edited - deleted - prereleased - released	リリースのタグが付いた直近のコミット	リリースのタグ

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

たとえば、リリースが published だったときにワークフローを実行する例は、次のとおりです。

on:
  release:
    types: [published]

ステータス

Git コミットのステータスが変更された、それによって status イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「ステータス」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
ステータス	n/a	デフォルトブランチの直近のコミット	n/a

たとえば、status イベントが発生したときにワークフローを実行する例は、次のとおりです。

on:
  status

Watch

watch イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「Star を付ける」を参照してください。

webhook イベントのペイロード	アクティビティタイプ	GITHUB_SHA	GITHUB_REF
Watch	- started	デフォルトブランチの直近のコミット	デフォルトブランチ

デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

たとえば、誰かがリポジトリに Star を付け、それが Watch イベントをトリガーする started アクティブタイプである場合にワークフローを実行する例は、次のとおりです。

on:
  watch:
    types: [started]

前回のワークフロー実行の結果に基づいて条件付きでワークフロージョブを実行する場合、jobs.<job_id>.if または jobs.<job_id>.steps[*].if 条件を前回の実行の conclusion と組み合わせて使用できます。 例:

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

jobs:
  on-success:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      ...
  on-failure:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    steps:
      ...

個人アクセストークンを使った新しいワークフローのトリガー

リポジトリのGITHUB_TOKENを使ってGitHub Actions アプリケーションの代わりにタスクを実行した場合、そのGITHUB_TOKENによって生じたイベントは、新たなワークフローの実行を生じさせません。 これによって、予想外の再帰的なワークフローの実行が生じないようになります。 たとえば、ワークフローの実行によってリポジトリのGITHUB_TOKENを使ったコードのプッシュが行われた場合、そのリポジトリにpushイベントが生じた際に実行されるよう設定されたワークフローが含まれていても、新しいワークフローの実行は行われません。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。

ワークフローの実行からワークフローをトリガーしたい場合意は、個人アクセストークンを使ってイベントをトリガーできます。 個人アクセストークンを作成し、それをシークレットとして保存する必要があります。 GitHub Actionsの利用コストを最小化するために、再帰的あるいは意図しないワークフローの実行が生じないようにしてください。 個人アクセストークンのシークレットとしての保存に関する詳しい情報については「暗号化されたシークレットの作成と保存」を参照してください。