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

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

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

GitHub Actions is currently in limited public beta and is subject to change. We strongly recommend that you do not use this feature for high-value workflows and content during the beta period. For more information about the beta, see "About GitHub Actions."

For more information about using GitHub Actions, see "Automating your workflow with GitHub Actions."

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

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

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

Note: The webhook payload available to GitHub Actions does not include the added, removed, and modified attributes in the commit object. You can retrieve the full commit object using the REST API. For more information, see "Get a single commit" in GitHub 開発者ドキュメンテーション".

誰かがリポジトリブランチにプッシュし、それによって 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 時間にワークフローを実行できるようスケジュール設定できます。 スケジュールしたワークフローは、デフォルトまたはベースブランチの直近のコミットで実行されます。 The shortest interval you can run scheduled workflows is once every 5 minutes.

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

担当者にお尋ねください

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

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