ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。
GitHub AEは、現在限定リリース中です。詳細については営業チームにお問い合わせください。

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

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

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

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

ノート: GITHUB_TOKENを使って新しいワークフローの実行をトリガーすることはできません。 詳しい情報については「個人アクセストークンを使った新しいワークフローのトリガー」を参照してください。

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

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

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

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

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

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

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

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

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

スケジュール

webhook イベントのペイロードアクティビティタイプGITHUB_SHAGITHUB_REF
n/an/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 分)。

注釈: GitHub Actions は、非標準的構文 (@yearly@monthly@weekly@daily@hourly@reboot) をサポートしていません。

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

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

手動イベント

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

workflow_dispatch

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

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

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

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

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

サンプル

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

on: workflow_dispatch

ワークフロー設定の例

この例では、 namehomeの入力を定義し、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_SHAGITHUB_REF
repository_dispatchn/aデフォルトブランチの直近のコミットデフォルトブランチ

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

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

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

サンプル

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

on:
  repository_dispatch:
    types: [opened, deleted]

webhook イベント

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

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

check_run

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

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

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

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

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

on:
  check_run:
    types: [rerequested, completed]

check_suite

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

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

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

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

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

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

on:
  check_suite:
    types: [rerequested, completed]

create

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

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

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

on:
  create

delete

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

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

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

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

on:
  delete

deployment

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

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

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

on:
  deployment

deployment_status

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

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

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

on:
  deployment_status

注釈: デプロイメントステータスの状態が inactive に設定されている場合、webhook イベントは作成されません。

フォーク

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

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

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

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

on:
  fork

gollum

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

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

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

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

on:
  gollum

issue_comment

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

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

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

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

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

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

ラベル

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

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

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

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

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

on:
  label:
    types: [created, deleted]

マイルストーン

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

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

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

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

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

on:
  milestone:
    types: [opened, deleted]

page_build

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

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

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

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

on:
  page_build

project

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

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

webhook イベントのペイロードアクティビティタイプGITHUB_SHAGITHUB_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_SHAGITHUB_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_SHAGITHUB_REF
project_column- created
- updated
- moved
- deleted
デフォルトブランチの直近のコミットデフォルトブランチ

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

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

on:
  project_column:
    types: [created, deleted]

public

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

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

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

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

on:
  public

pull_request

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

ノート:

  • By default, a workflow only runs when a pull_request's activity type is opened, synchronize, or reopened. 他のアクティビティタイプについてもワークフローをトリガーするには、types キーワードを使用してください。
  • Workflows will not run on pull_request activity if the pull request has a merge conflict. The merge conflict must be resolved first.
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

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

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

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

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

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

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

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

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

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

pull_request_review

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

webhook イベントのペイロードアクティビティタイプGITHUB_SHAGITHUB_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をオープンした場合には、プライベートのベースリポジトリではワークフローは実行されません。

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

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

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

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

pull_request_review_comment

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

webhook イベントのペイロードアクティビティタイプGITHUB_SHAGITHUB_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をオープンした場合には、プライベートのベースリポジトリではワークフローは実行されません。

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

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

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

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

pull_request_target

このイベントはpull_requestのようにマージコミット内ではなく、Pull Requestのベースのコンテキストで実行されます。 これにより、リポジトリを変更したり、ワークフローで使うシークレットを盗んだりするような、Pull Requestのヘッドからの安全ではないワークフローのコードが実行されるのを避けられます。 このイベントでは、イベントペイロードの内容に基づいて、プルリクエストにラベルを付けてコメントを付けるワークフローを作成するようなことができます。

警告: pull_request_targetイベントは、フォークからトリガーされた場合であっても、リポジトリトークンの読み書きが許可されており、シークレットにアクセスできます。 ワークフローはPull Requestのベースのコンテキストで実行されますが、このイベントでPull Requestから信頼できないコードをチェックアウトしたり、ビルドしたり、実行したりしないようにしなければなりません。 加えて、ベースブランチと同じスコープを共有するキャッシュがあり、キャッシュが汚染されることを避けるために、キャッシュの内容が変更されている可能性があるなら、キャッシュを保存するべきではありません。 詳細については、GitHub Security Lab Web サイトの「GitHub Actions とワークフローを安全に保つ: pwn リクエストの防止」を参照してください。

webhook イベントのペイロードアクティビティタイプGITHUB_SHAGITHUB_REF
pull_request_target- 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 ベースブランチ

デフォルトでは、ワークフローは、pull_request_target のアクティビティタイプが openedsynchronize、または reopened のときにのみ実行されます。 他のアクティビティタイプについてもワークフローをトリガーするには、types キーワードを使用してください。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。

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

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

プッシュ

ノート: GitHub Actionsが利用できるwebhookのペイロードには、commitオブジェクト中のaddedremovedmodified属性は含まれません。 完全なcommitオブジェクトは、REST APIを使って取得できます。 詳しい情報については、「1つのコミットの取得」を参照してください。

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

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

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

on:
  push

registry_package

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

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

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

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

on:
  registry_package:
    types: [published]

リリース

注釈: release イベントは、ドラフトリリースではトリガーされません。

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

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

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

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

on:
  release:
    types: [published]

注釈: prereleased タイプは、ドラフトリリースから公開されたプレリリースではトリガーされませんが、published タイプはトリガーされます。 安定版およびプレリリースの公開時にワークフローを実行する場合は、released および prereleased ではなく published にサブスクライブします。

ステータス

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

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

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

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

on:
  status

Watch

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

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

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

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

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

on:
  watch:
    types: [started]

workflow_run

このイベントは、ワークフローの実行がリクエストされたか完了した場合に生じ、他のワークフローの終了した結果に基づいてワークフローを実行できるようにしてくれます。 ワークフローの実行は、以前のワークフローの結果にかかわらずトリガーされます。

たとえば、pull_requestワークフローがビルドの成果物を生成するなら、workflow_runを使って結果を分析し、オリジナルのPull Requestにコメントする新しいワークフローを作成できます。

workflow_runイベントによってStarされたワークフローは、以前のワークフローができなくても、シークレットや書き込みトークンにアクセスできます。 これは、以前のワークフローが意図的に権限を与えられていない場合に役立ちますが、権限を与えられたアクションは後のワークフローで行わなければなりません。

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

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

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

このイベントからブランチをフィルタする必要がある場合は、branches または branches-ignore を使用できます。

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

on:
  workflow_run:
    workflows: ["Run Tests"]
    branches: [main]
    types: 
      - completed
      - requested

前回のワークフロー実行の結果に基づいて条件付きでワークフロージョブを実行する場合、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の利用コストを最小化するために、再帰的あるいは意図しないワークフローの実行が生じないようにしてください。 個人アクセストークンのシークレットとしての保存に関する詳しい情報については「暗号化されたシークレットの作成と保存」を参照してください。

このドキュメントは役立ちましたか?

プライバシーポリシー

これらのドキュメントを素晴らしいものにするのを手伝ってください!

GitHubのすべてのドキュメントはオープンソースです。間違っていたり、はっきりしないところがありましたか?Pull Requestをお送りください。

コントリビューションを行う

OR, コントリビューションの方法を学んでください。

問題がまだ解決していませんか?