ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。
GitHub AE is currently under limited release. Please contact our Sales Team to find out more.

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

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

GitHub ActionsはGitHub Free、GitHub Pro、GitHub FreeのOrganization、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Server、GitHub One、GitHub AEで利用できます。 GitHub Actionsは、レガシーのリポジトリごとのプランを使っているアカウントが所有しているプライベートリポジトリでは利用できません。

ここには以下の内容があります:

ノート: GitHub Actionsは現在GitHub AEでベータです。

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

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

1つのイベントを使用する例
# リポジトリ内の任意のブランチにコードがプッシュされたときにトリガーされる
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のワークフローの実行による高負荷の間、遅延させられることがあります。 高負荷の時間帯には、毎時の開始時点が含まれます。 遅延の可能性を減らすために、Ⅰ時間の中の別の時間帯に実行されるようワークフローをスケジューリングしてください。

schedule

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

POSIX クーロン構文を使用して、特定の UTC 時間にワークフローを実行できるようスケジュール設定できます。 スケジュールしたワークフローは、デフォルトまたはベースブランチの直近のコミットで実行されます。 スケジュールされたワークフローを実行できる最短の間隔は、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 * * *'

クーロン構文では、スペースで分けられた 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 コンテキスト内の入力値にアクセスできます。 詳しい情報については、「GitHub Actions のコンテキストと式構文」を参照してください。

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
ワークフロー設定の例

この例では、 codehomeを入力として定義し、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 イベント

You can configure your workflow to run when webhook events are generated on GitHub AE. イベントによっては、そのイベントをトリガーするアクティビティタイプが 複数あります。 イベントをトリガーするアクティビティタイプが複数ある場合は、ワークフローの実行をトリガーするアクティビティタイプを指定できます。 詳しい情報については、「webhook」を参照してください。

Not all webhook events trigger workflows. For the complete list of available webhook events and their payloads, see "Webhook events and payloads."

check_run

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

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

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

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

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

on:
  check_run:
    types: [rerequested, requested_action]

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 イベントは作成されません。

fork

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

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

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

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

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

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

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

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

on:
  label:
    types: [created, deleted]

milestone

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

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

webhook イベントのペイロードアクティビティタイプGITHUB_SHAGITHUB_REF
milestone- 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: [opened, 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つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「プルリクエスト」を参照してください。

注: デフォルトでは、ワークフローが実行されるのはpull_request のアクティビティタイプが openedsynchronize、または reopened の場合だけです。 他のアクティビティタイプについてもワークフローをトリガーするには、types キーワードを使用してください。

webhook イベントのペイロードアクティビティタイプGITHUB_SHAGITHUB_REF
pull_request- assigned
- unassigned
- labeled
- unlabeled
- opened
- edited
- closed
- reopened
- synchronize
- ready_for_review
- locked
- unlocked
- review_requested
- review_request_removed
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つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「プルリクエストレビュー」を参照してください。

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

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

たとえば、プルリクエストレビューが eidted または 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つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「レビューコメント」を参照してください。

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
- ready_for_review
- locked
- unlocked
- review_requested
- review_request_removed
PR ベースブランチの直近のコミットPR ベースブランチ

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

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

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

push

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

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

webhook イベントのペイロードアクティビティタイプGITHUB_SHAGITHUB_REF
pushn/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 イベントは、ドラフトリリースではトリガーされません。

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

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

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

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

on:
  release:
    types: [published]

status

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

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

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

This event occurs when a workflow run is requested or completed, and allows you to execute a workflow based on the finished result of another workflow. A workflow run is triggered regardless of the result of the previous workflow.

For example, if your pull_request workflow generates build artifacts, you can create a new workflow that uses workflow_run to analyze the results and add a comment to the original pull request.

The workflow started by the workflow_run event is able to access secrets and write tokens, even if the previous workflow was not. This is useful in cases where the previous workflow is intentionally not privileged, but you need to take a privileged action in a later workflow.

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

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

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

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

In this example, a workflow is configured to run after the separate "Run Tests" workflow completes.

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

To run a workflow job conditionally based on the result of the previous workflow run, you can use the jobs.<job_id>.if or jobs.<job_id>.steps[*].if conditional combined with the conclusion of the previous run. 例:

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

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.