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

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

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

GitHub ActionsはGitHub Free、GitHub Pro、GitHub FreeのOrganization、GitHub Team、GitHub Enterprise Cloud、GitHub Oneで利用できます。 GitHub Actions is not available for private repositories owned by accounts using legacy per-repository plans. 詳しい情報については「GitHubの製品」を参照してください。

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

Did this doc help you?

GitHubは、macOSランナーのホストにMacStadiumを使用しています。

ワークフローイベントについて

GitHub 上のアクティビティから webhook イベントが作成された際にワークフローを実行するよう設定できます。 ワークフローは、ワークフローの実行をトリガーするための webhook イベントを複数使用できます。 詳しい情報については、「webhook」を参照してください。 on 構文の詳細については、「GitHub Actionsのためのワークフローの構文」を参照してください。

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

  1. リポジトリでイベントが生じ、その結果のイベントのwebhookは関連づけられたコミットSHAとGit refを持っている。

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

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

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

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

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

1つのイベントを使用する例
# プッシュでトリガー
on: push
イベントのリストを使用する例
# プッシュあるいはプルリクエストでワークフローをトリガー
on: [push, pull_request]
アクティビティの種類もしくは設定を伴う複数のイベントを使用する例

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

on:
  # プッシュもしくはプルリクエストでワークフローを起動する
  # ただしmasterブランチに対してのみ
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
  # page_buildとリリース作成イベントでも起動
  page_build:
  release:
    types: # この設定は上のpage_buildイベントには影響しない
      - created

webhook イベント

GitHub で webhook イベントが作成された際にワークフローを実行するよう設定できます。 イベントによっては、そのイベントをトリガーするアクティビティタイプが 複数あります。 イベントをトリガーするアクティビティタイプが複数ある場合は、ワークフローの実行をトリガーするアクティビティタイプを指定できます。

check_run

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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 の詳細については、「チェックスイート」を参照してください。

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

ノート: 再帰的なワークフローを避けるために、このイベントは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

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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

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

on:
  delete

deployment

誰かがデプロイメントを作成し、それによって deploymen イベントがトリガーされるときにワークフローを実行します。 コミット 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

フォーク

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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

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

on:
  fork

gollum

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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

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

on:
  gollum

issue_comment

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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

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

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

on:
  issue_comment:
    types: [created, deleted]

issues

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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 の詳細については、「ラベル」を参照してください。

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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

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

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

on:
  label:
    types: [created, deleted]

マイルストーン

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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

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

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

on:
  milestone:
    types: [opened, deleted]

page_build

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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

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

on:
  page_build

project

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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 の詳細については、「プロジェクトカード」を参照してください。

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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 の詳細については、「プロジェクト列」を参照してください。

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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 の詳細については、「リポジトリの編集」を参照してください。

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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]
フォークしたリポジトリのプルリクエストイベント

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

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

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

フォークしたリポジトリ内の GITHUB_TOKEN への権限は、読み取りのみです。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。

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]
フォークしたリポジトリのプルリクエストイベント

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

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

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

フォークしたリポジトリ内の GITHUB_TOKEN への権限は、読み取りのみです。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。

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]
フォークしたリポジトリのプルリクエストイベント

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

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

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

フォークしたリポジトリ内の GITHUB_TOKEN への権限は、読み取りのみです。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。

pull_request_target

このイベントは pull_request に似ていますが、マージコミットではなく、プルリクエストのベースリポジトリのコンテキストで実行される点で異なります。 つまり、ベースリポジトリのコミットで定義されたワークフローのみが実行されるため、プルリクエストによってトリガーされたワークフローでシークレットをより安全に使用できるようになります。 たとえば、このイベントでは、イベントペイロードの内容に基づいて、プルリクエストにラベルを付けてコメントを付けるワークフローを作成できます。

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
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]

ステータス

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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

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

on:
  status

Watch

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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. 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 the secrets and write tokens used by the original workflow.

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

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

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

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

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

schedule

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

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

以下の例では、15分ごとにワークフローを実行します。

on:
  schedule:
    # * はYAMLに置ける特殊文字なので、この文字列は引用符で囲まなければならない
    - cron:  '*/15 * * * *'

クーロン構文では、スペースで分けられた 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 ブランチ上の直近のコミットディスパッチを受信したブランチ

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

GitHub でイベントをトリガーすると、GitHub で refinputs を直接入力できます。 詳細は「ワークフローの設定」を参照してください。

repository_dispatch

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

ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。

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

」を参照してください。

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

サンプル

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

on:
  repository_dispatch:
    types: [opened, deleted]

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

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

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

Did this doc help you?