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

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

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

GitHub Actions is available with GitHub Free, GitHub Pro, GitHub Team, and GitHub Enterprise Cloud. GitHub Actions is unavailable for per-repository plans, which are legacy billing plans. For more information, see "GitHub's products."

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

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

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

実行しているワークフローのアクションからは、新しいワークフローの実行をトリガーできません。 たとえば、リポジトリの GITHUB_TOKEN を使ってアクションがコードをプッシュしている場合、push イベントの発生時には、そのリポジトリが、新しいワークフローを実行するよう設定されているワークフローを含んでいる場合であっても、新しいワークフローは実行できません。

コミット SHA およびGit ref によって特定される、リポジトリ内のコードの特定のバージョンにおいて、ワークフローは動作します。 GitHub は、webhook イベントペイロードを使用して、イベントをトリガーしたコミット SHA および Git ref を特定します。 ワークフローを実行すると、GitHub はバーチャル環境において GITHUB_SHA (コミット SHA) および GITHUB_REF (Git ref) 環境変数を設定します。 詳しい情報については、「環境変数」を参照してください。

1 つのイベントを使用するサンプル

on: push

複数のイベントを使用するサンプル

# Use an array when using more than one event
on: [push, pull_request]

webhook イベント

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

チェック実行イベント: check_run

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

webhook イベントのペイロード アクティビティタイプ GITHUB_SHA GITHUB_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 開発者ドキュメンテーション で「チェックスイート」を参照してください。

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 の詳細については、GitHub 開発者ドキュメンテーションで「リファレンスの作成」を参照してください。

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

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

on:
  create

削除イベント: delete

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

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

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

on:
  delete

デプロイメントイベント: deployment

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

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

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

on:
  deployment

デプロイメントステータスイベント: deployment_status

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

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

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

on:
  deployment_status

フォークイベント: fork

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

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

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

on:
  fork

gollumイベント: gollum

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

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

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

on:
  gollum

Issue コメントイベント: issue_comment

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

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

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

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

on:
  issue_comment:
    types: [created, deleted]

Issue イベント: issues

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

webhook イベントのペイロード アクティビティタイプ GITHUB_SHA GITHUB_REF
Issue -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 の詳細については、GitHub 開発者ドキュメンテーション で「ラベル」を参照してください。

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

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

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

on:
  label:
    types: [created, deleted]

メンバーイベント: member

member イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、GitHub 開発者ドキュメンテーション で「コラボレータ」を参照してください。

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

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

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

on:
  member:
    types: [added, deleted]

マイルストーンイベント: milestone

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

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

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

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

on:
  milestone:
    types: [opened, deleted]

ページビルドイベント: page_build

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

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

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

on:
  page_build

プロジェクトイベント: project

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

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 の詳細については、GitHub 開発者ドキュメンテーション で「プロジェクトカード」を参照してください。

webhook イベントのペイロード アクティビティタイプ GITHUB_SHA GITHUB_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 の詳細については、GitHub 開発者ドキュメンテーション で「プロジェクト列」を参照してください。

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 の詳細については、GitHub 開発者ドキュメンテーションで「イベントリポジトリ」を参照してください。

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

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

on:
  public

プルリクエストイベント: pull_request

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

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

webhook イベントのペイロード アクティビティタイプ GITHUB_SHA GITHUB_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 のワークフロー構文」を参照してください。

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

on:
  pull_request:
    types: [assigned, opened, synchronize, reopened]
フォークしたリポジトリのプルリクエストイベント

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

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

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

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

プルリクエストレビューイベント: pull_request_review

pull_request_review イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、GitHub 開発者ドキュメンテーション で「プルリクエストレビュー」を参照してください。

webhook イベントのペイロード アクティビティタイプ GITHUB_SHA GITHUB_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 に関する詳しい情報については、「GitHub Actions の仮想環境」を参照してください。

プルリクエストレビューコメントイベント: pull_request_review_comment

プルリクエストの統合 diff へのコメントが変更され、それによって pull_request_review_comment イベントがトリガーされるときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、GitHub 開発者ドキュメンテーション で「レビューコメント」を参照してください。

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

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

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

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

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

プッシュイベント: push

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

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

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

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

on:
  push

リリースイベント: release

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

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

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

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

on:
  release:
    types: [published]

ステータスイベント: status

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

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

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

on:
  status

Watch イベント: watch

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

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

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

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

on:
  watch
    types: [started]

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

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

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

This example triggers the workflow every 15 minutes:

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - 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 のサンプルリストもあります。

外部イベント: repository_dispatch

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

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

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

サンプル

このイベントは追加のアクティブタイプがないため、types キーワードには対応していません。

on: repository_dispatch

担当者にお尋ねください

探しているものが見つからなかったでしょうか?

弊社にお問い合わせください