# ワークフローをトリガーするイベント
GitHubで特定のアクティビティが発生したとき、スケジュールされた時刻、またはGitHub外のイベントが発生したときに実行されるようにワークフローを構成できます。
## ワークフローをトリガーするイベントについて
ワークフロー トリガーは、ワークフローの実行を引き起こすイベントです。 ワークフロー トリガーの使い方について詳しくは、「[ワークフローをトリガーする](/ja/enterprise-server@3.22/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow)」をご覧ください。
イベントによっては、複数のアクティビティの種類があります。 このようなイベントでは、ワークフローの実行をトリガーするアクティビティの種類を指定できます。 各アクティビティの種類の意味について詳しくは、「[Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads)」をご覧ください。
> \[!NOTE]
> すべての Webhook イベントによってワークフローがトリガーされるわけではありません。
## `branch_protection_rule`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------ | ----------------- | ------------ |
| [`branch_protection_rule`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#branch_protection_rule) | - `created`
- `edited`
- `deleted` | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#branch_protection_rule) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
ワークフロー リポジトリ内のブランチ保護ルールが変更されたときにワークフローを実行します。 ブランチ保護ルールについて詳しくは、「[保護されたブランチについて](/ja/enterprise-server@3.22/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)」をご覧ください。 ブランチ保護ルール API については、GraphQL API ドキュメントの「[Branches](/ja/enterprise-server@3.22/graphql/reference/branches#object-branchprotectionrule)」または「[ブランチとその設定用 REST API エンドポイント](/ja/enterprise-server@3.22/rest/branches)」をご覧ください。
たとえば、ブランチ保護ルールが `created` または `deleted` だったときにワークフローを実行できます。
```yaml
on:
branch_protection_rule:
types: [created, deleted]
```
## `check_run`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ----------------- | ------------ |
| [`check_run`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_run) | - `created`
- `rerequested`
- `completed`
- `requested_action` | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_run) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
> * 再帰ワークフローを防ぐために、チェック実行のチェック スイートが GitHub Actions によって作成された場合、またはチェック スイートのヘッド SHA が GitHub Actionsに関連付けられている場合、このイベントはワークフローをトリガーしません。
チェック実行に関連するアクティビティが発生したときにワークフローを実行します。 チェックの実行は、個別のテストであり、チェックスイートの一機能です。 詳しくは、「[REST API を使用してチェックを操作する](/ja/enterprise-server@3.22/rest/guides/using-the-rest-api-to-interact-with-checks)」を参照してください。 チェック実行 API については、GraphQL API ドキュメントの「[チェック](/ja/enterprise-server@3.22/graphql/reference/checks#object-checkrun)」または「[チェック実行用 REST API エンドポイント](/ja/enterprise-server@3.22/rest/checks/runs)」をご覧ください。
たとえば、チェック実行が `rerequested` または `completed` だったときにワークフローを実行できます。
```yaml
on:
check_run:
types: [rerequested, completed]
```
## `check_suite`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------------------- | ------------- | ----------------- | ------------ |
| [`check_suite`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_suite) | - `completed` | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_suite) を参照してください。 アクティビティの種類 `completed` のみがサポートされていますが、このアクティビティの種類を指定すると、今後さらにアクティビティの種類が追加された場合に、ワークフローを特定のもののままにできます。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
> * 再帰ワークフローを防ぐために、このイベントは、チェック スイートが GitHub Actions によって作成された場合、またはチェック スイートのヘッド SHA が GitHub Actionsに関連付けられている場合、ワークフローをトリガーしません。
チェック スイートのアクティビティが発生したときにワークフローを実行します。 チェック スイートは、特定のコミットに対して作成されたチェック実行のコレクションです。 チェック スイートでは、スイート内のチェック実行の状態と結果をまとめます。 詳しくは、「[REST API を使用してチェックを操作する](/ja/enterprise-server@3.22/rest/guides/using-the-rest-api-to-interact-with-checks)」を参照してください。 チェック スイート API については、GraphQL API ドキュメントの「[チェック](/ja/enterprise-server@3.22/graphql/reference/checks#object-checksuite)」または「[チェック スイート用 REST API エンドポイント](/ja/enterprise-server@3.22/rest/checks/suites)」をご覧ください。
たとえば、チェック スイートが `completed` だったときにワークフローを実行できます。
```yaml
on:
check_suite:
types: [completed]
```
## `create`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------- | ---------- | ---------------------- | -------------- |
| [`create`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#create) | 該当なし | 作成されたブランチまたはタグの最後のコミット | 作成されたブランチまたはタグ |
> \[!NOTE]
> 一度に 3 つより多くのタグを作成した場合、イベントは作成されません。
誰かがワークフローのリポジトリに Git 参照 (Git ブランチまたはタグ) を作成したときにワークフローを実行します。 Git 参照を作成するための API については、GraphQL API ドキュメントの「[Git](/ja/enterprise-server@3.22/graphql/reference/git#mutation-createref)」または「[Git リファレンス用 REST API エンドポイント](/ja/enterprise-server@3.22/rest/git/refs#create-a-reference)」をご覧ください。
たとえば、`create` イベントが発生したときにワークフローを実行できます。
```yaml
on:
create
```
## `delete`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------- | ---------- | ----------------- | ------------ |
| [`delete`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#delete) | 該当なし | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
> * 一度に 3 つより多くのタグを削除した場合、イベントは作成されません。
誰かがワークフローのリポジトリで Git 参照 (Git ブランチまたはタグ) を削除したときにワークフローを実行します。 Git 参照を削除するための API については、GraphQL API ドキュメントの「[Git](/ja/enterprise-server@3.22/graphql/reference/git#mutation-deleteref)」または「[Git リファレンス用 REST API エンドポイント](/ja/enterprise-server@3.22/rest/git/refs#delete-a-reference)」をご覧ください。
たとえば、`delete` イベントが発生したときにワークフローを実行できます。
```yaml
on:
delete
```
## `deployment`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------ | ---------- | ------------ | --------------------------------------- |
| [`deployment`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#deployment) | 該当なし | デプロイされるコミット | デプロイするブランチまたはタグ (コミット SHA 付きで作成された場合は空) |
誰かがワークフローのリポジトリにデプロイを作成したときにワークフローを実行します。 コミット SHA を使って作成されたデプロイには、Git ref がない場合があります。デプロイを作成するための API については、「[デプロイ](/ja/enterprise-server@3.22/graphql/reference/deployments#mutation-createdeployment)」(GraphQL API ドキュメント) または「[リポジトリの REST API エンドポイント](/ja/enterprise-server@3.22/rest/repos#deployments)」をご覧ください。
たとえば、`deployment` イベントが発生したときにワークフローを実行できます。
```yaml
on:
deployment
```
## `deployment_status`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------------------------------- | ---------- | ------------ | ---------------------------- |
| [`deployment_status`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#deployment_status) | 該当なし | デプロイされるコミット | デプロイされるブランチまたはタグ (コミットの場合は空) |
> \[!NOTE]
> デプロイの状態が `inactive` に設定されている場合、ワークフローの実行はトリガーされません。
サード パーティによってデプロイの状態が提供されたときにワークフローを実行します。 コミット SHA を使って作成されたデプロイには、Git ref がない場合があります。デプロイ状態を作成するための API については、GraphQL API ドキュメントの「[デプロイ](/ja/enterprise-server@3.22/graphql/reference/deployments#mutation-createdeploymentstatus)」または「[デプロイ用の REST API エンドポイント](/ja/enterprise-server@3.22/rest/deployments#create-a-deployment-status)」をご覧ください。
たとえば、`deployment_status` イベントが発生したときにワークフローを実行できます。
```yaml
on:
deployment_status
```
## `discussion`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | ------------ |
| [`discussion`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#discussion) | - `created`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `category_changed`
- `answered`
- `unanswered` | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#discussion) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
> * GitHub Discussions の Webhook イベントは パブリック プレビュー 段階であり、変更される可能性があります。
ワークフローのリポジトリ内のディスカッションが作成または変更されたときにワークフローを実行します。 ディスカッションのコメントに関連するアクティビティには、[`discussion_comment`](#discussion_comment) イベントを使います。 ディスカッションについて詳しくは、「[ディスカッションについて](/ja/enterprise-server@3.22/discussions/collaborating-with-your-community-using-discussions/about-discussions)」をご覧ください。 GraphQL API については、「[ディスカッション](/ja/enterprise-server@3.22/graphql/reference/discussions#object-discussion)」をご覧ください。
たとえば、ディスカッションが `created`、`edited`、または `answered` だったときにワークフローを実行できます。
```yaml
on:
discussion:
types: [created, edited, answered]
```
## `discussion_comment`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | ----------------- | ------------ |
| [`discussion_comment`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#discussion_comment) | - `created`
- `edited`
- `deleted`
| デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#discussion_comment) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
> * GitHub Discussions の Webhook イベントは パブリック プレビュー 段階であり、変更される可能性があります。
ワークフローのリポジトリ内のディスカッションのコメントが作成または変更されたときにワークフローを実行します。 ディスカッションのコメントではなくディスカッションに関連するアクティビティには、[`discussion`](#discussion) イベントを使います。 ディスカッションについて詳しくは、「[ディスカッションについて](/ja/enterprise-server@3.22/discussions/collaborating-with-your-community-using-discussions/about-discussions)」をご覧ください。 GraphQL API については、「[ディスカッション](/ja/enterprise-server@3.22/graphql/reference/discussions#object-discussion)」をご覧ください。
たとえば、ディスカッション コメントが `created` または `deleted` だったときにワークフローを実行できます。
```yaml
on:
discussion_comment:
types: [created, deleted]
```
## `fork`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------ | ---------- | ----------------- | ------------ |
| [`fork`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#fork) | 該当なし | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
誰かがリポジトリをフォークしたときにワークフローを実行します。 REST API については、「[フォーク用の REST API エンドポイント](/ja/enterprise-server@3.22/rest/repos/forks#create-a-fork)」をご覧ください。
たとえば、`fork` イベントが発生したときにワークフローを実行できます。
```yaml
on:
fork
```
## `gollum`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------- | ---------- | ----------------- | ------------ |
| [`gollum`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#gollum) | 該当なし | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
誰かが Wiki ページを作成または更新したときにワークフローを実行します。 詳しくは、「[ウィキについて](/ja/enterprise-server@3.22/communities/documenting-your-project-with-wikis/about-wikis)」をご覧ください。
たとえば、`gollum` イベントが発生したときにワークフローを実行できます。
```yaml
on:
gollum
```
## `image_version`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------ | ---------- | ----------------- | ------------ |
| 該当なし | 該当なし | デフォルトブランチの直近のコミット | デフォルトブランチ |
指定したイメージの新しいバージョンが使用できるようになると、ワークフローを実行します。 このイベントは通常、イメージ バージョンの作成が成功した後にトリガーされ、新しいイメージ バージョンに応答してデプロイや通知などのアクションを自動化できます。
このイベントは、イメージ名とバージョンの両方の glob パターンをサポートします。 次の例では、新しいイメージ バージョンが、指定した名前とバージョンの組み合わせのいずれかに一致するとトリガーされます。 たとえば、 `["MyNewImage", 1.0.0]`、 `["MyNewImage", 2.53.0]`、 `["MyOtherImage", 1.0.0]`、 `["MyOtherImage", 2.0.0]`などです。
```yaml
on:
image_version:
names:
- "MyNewImage"
- "MyOtherImage"
versions:
- 1.*
- 2.*
```
## `issue_comment`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------------ | ----------------------------------------------- | ----------------- | ------------ |
| [`issue_comment`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#issue_comment) | - `created`
- `edited`
- `deleted`
| デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#issue_comment) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
issue または pull request のコメントが作成、編集、または削除されたときにワークフローを実行します。 issue コメント API についての情報は、GraphQL API ドキュメントの「[課題](/ja/enterprise-server@3.22/graphql/reference/issues#object-issuecomment)」または REST API ドキュメントの「[Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#issue_comment)」をご確認ください。
たとえば、issue または pull request のコメントが `created` または `deleted` だったときにワークフローを実行できます。
```yaml
on:
issue_comment:
types: [created, deleted]
```
### 問題のみまたはプル リクエストのみの `issue_comment`
`issue_comment` イベントは、issue と pull request の両方に関するコメントで発生します。 条件で `github.event.issue.pull_request` プロパティを使うと、トリガーするオブジェクトが issue か pull request かによって異なるアクションを実行できます。
たとえば、このワークフローでは、`pr_commented` イベントが pull request から発生した場合にのみ `issue_comment` ジョブを実行します。
`issue_commented` イベントが issue から発生した場合にのみ `issue_comment` ジョブが実行されます。
```yaml
on: issue_comment
jobs:
pr_commented:
# This job only runs for pull request comments
name: PR comment
if: ${{ github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo A comment on PR $NUMBER
env:
NUMBER: ${{ github.event.issue.number }}
issue_commented:
# This job only runs for issue comments
name: Issue comment
if: ${{ !github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo A comment on issue $NUMBER
env:
NUMBER: ${{ github.event.issue.number }}
```
## `issues`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------- | ------------ |
| [`issues`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#issues) | - `opened`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `closed`
- `reopened`
- `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `milestoned`
- `demilestoned`
- `typed`
- `untyped` | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#issues) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
ワークフローのリポジトリ内の issue が作成または変更されたときにワークフローを実行します。 issue のコメントに関連するアクティビティには、[`issue_comment`](#issue_comment) イベントを使います。 問題について詳しくは、「[問題について](/ja/enterprise-server@3.22/issues/tracking-your-work-with-issues/learning-about-issues/about-issues)」をご覧ください。 issue API について詳しくは、GraphQL API ドキュメントの「[課題](/ja/enterprise-server@3.22/graphql/reference/issues#object-issue)」または「[問題用の REST API エンドポイント](/ja/enterprise-server@3.22/rest/issues)」をご覧ください。
たとえば、issue が `opened`、`edited`、または `milestoned` だったときにワークフローを実行できます。
```yaml
on:
issues:
types: [opened, edited, milestoned]
```
## `label`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------- | ----------------------------------------------- | ----------------- | ------------ |
| [`label`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#label) | - `created`
- `edited`
- `deleted`
| デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#label) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
ワークフローのリポジトリ内のラベルが作成または変更されたときにワークフローを実行します。 ラベルについて詳しくは、「[ラベルを管理する](/ja/enterprise-server@3.22/issues/using-labels-and-milestones-to-track-work/managing-labels)」をご覧ください。 ラベル API については、GraphQL API ドキュメントの「[課題](/ja/enterprise-server@3.22/graphql/reference/issues#object-label)」または「[ラベル用の REST API エンドポイント](/ja/enterprise-server@3.22/rest/issues/labels)」をご覧ください。
issue、pull request、またはディスカッションにラベルが追加されるか削除されたときにワークフローを実行したい場合は、代わりに `labeled` または `unlabeled` アクティビティタイプを [`issues`](#issues)、[`pull_request`](#pull_request)、[`pull_request_target`](#pull_request_target)、または [`discussion`](#discussion) イベントに使用します。
たとえば、ラベルが `created` または `deleted` だったときにワークフローを実行できます。
```yaml
on:
label:
types: [created, deleted]
```
## `merge_group`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------------------- | ------------------ | ------------- | ------------- |
| [`merge_group`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#merge_group) | `checks_requested` | マージ グループの SHA | マージ グループの ref |
> \[!NOTE]
>
> *
このイベントは、2つ以上の種類のアクティビティで起動されます。
`checks_requested` アクティビティの種類のみがサポートされていますが、今後追加されるアクティビティの種類が増える場合、アクティビティの種類を指定してもワークフロー固有の状態が維持されます。 各アクティビティの種類については、「[Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#merge_group)」をご覧ください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
`types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
> * リポジトリで GitHub Actions を使用して、リポジトリ内の pull request において必要なチェックを実行する場合、または組織のルールセットを介するワークフローが必要な場合は、追加のトリガーとして `merge_group` イベントを含むようにワークフローを更新する必要があります。 それ以外の場合、マージ キューに pull request を追加しても、ステータス チェックがトリガーされません。 必要な状態チェックが報告されないため、マージは失敗します。 `merge_group` イベントは、`pull_request` および `push` イベントとは異なります。
マージ キューに pull request が追加されたときにワークフローを実行し、マージ グループにその pull request を追加します。 詳しくは、「[pull request とマージ キューのマージ](/ja/enterprise-server@3.22/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request-with-a-merge-queue)」をご覧ください。
たとえば、`checks_requested` イベントが発生したときにワークフローを実行できます。
```yaml
on:
pull_request:
branches: [ "main" ]
merge_group:
types: [checks_requested]
```
## `milestone`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ----------------- | ------------ |
| [`milestone`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#milestone) | - `created`
- `closed`
- `opened`
- `edited`
- `deleted`
| デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#milestone) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
ワークフローのリポジトリ内のマイルストーンが作成または変更されたときにワークフローを実行します。 マイルストーンについて詳しくは、「[マイルストーンについて](/ja/enterprise-server@3.22/issues/using-labels-and-milestones-to-track-work/about-milestones)」をご覧ください。 マイルストーン API については、GraphQL API ドキュメントの「[課題](/ja/enterprise-server@3.22/graphql/reference/issues#object-milestone)」または「[マイルストーン用の REST API エンドポイント](/ja/enterprise-server@3.22/rest/issues/milestones)」をご覧ください。
マイルストーンに課題が追加または削除されたときにワークフローを実行したい場合は、`milestoned` イベントではなく、代わりにアクティビティの種類として `demilestoned` または `issues` を使用してください。
たとえば、マイルストーンが `opened` または `deleted` だったときにワークフローを実行できます。
```yaml
on:
milestone:
types: [opened, deleted]
```
## `page_build`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------ | ---------- | ----------------- | ------------ |
| [`page_build`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#page_build) | 該当なし | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
リポジトリに対してGitHub Pagesが有効になっている場合、誰かがGitHub Pagesの発行元であるブランチにプッシュしたときにワークフローを実行します。
GitHub Pages発行ソースの詳細については、「[GitHub Pages サイトの発行ソースの構成](/ja/enterprise-server@3.22/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site)」を参照してください。 REST API については、「[リポジトリの REST API エンドポイント](/ja/enterprise-server@3.22/rest/repos#pages)」をご覧ください。
たとえば、`page_build` イベントが発生したときにワークフローを実行できます。
```yaml
on:
page_build
```
## `public`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------- | ---------- | ----------------- | ------------ |
| [`public`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#public) | 該当なし | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
ワークフローのリポジトリがプライベートからパブリックに変更されたときにワークフローを実行します。 REST API については、「[リポジトリの REST API エンドポイント](/ja/enterprise-server@3.22/rest/repos#edit)」をご覧ください。
たとえば、`public` イベントが発生したときにワークフローを実行できます。
```yaml
on:
public
```
## `pull_request`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | ------------ |
| [`pull_request`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `locked`
- `unlocked`
- `milestoned`
- `demilestoned`
- `ready_for_review`
- `review_requested`
- `review_request_removed`
- `auto_merge_enabled`
- `auto_merge_disabled` | | |
| `GITHUB_REF` ブランチでの最後のマージ コミット | PR マージ ブランチ `refs/pull/PULL_REQUEST_NUMBER/merge` | | |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#pull_request) を参照してください。 既定では、ワークフローは、`pull_request` イベントのアクティビティの種類が `opened`、`synchronize`、または `reopened`にのみ実行されます。 さまざまなアクティビティの種類でワークフローをトリガーするには、`types` キーワードを使います。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * pull request にマージの競合がある場合、`pull_request` アクティビティではワークフローは実行されません。 最初にマージ競合を解決する必要があります。 逆に、`pull_request_target` イベントを含むワークフローは、pull request にマージの競合がある場合でも実行されます。
> `pull_request_target` トリガーを使う前に、セキュリティ リスクに注意する必要があります。 詳細については、「[`pull_request_target`](#pull_request_target)」を参照してください。
> *
`pull_request`Webhookイベントのペイロードは、マージされたプルリクエストとフォークされたリポジトリからのプルリクエストでは空です。
> ***
`GITHUB_REF` の値は、プルリクエストがマージされたかどうかに応じて、クローズされたプルリクエストの場合、異なります。 pull request はクローズされたが、マージされていない場合は `refs/pull/PULL_REQUEST_NUMBER/merge` になります。 マージの結果としてプル リクエストがクローズされた場合は、マージ先のブランチの完全修飾の `ref` (`/refs/heads/main` など) になります。
ワークフローのリポジトリ内の pull request のアクティビティが発生したときにワークフローを実行します。 たとえば、アクティビティの種類が指定されていない場合、pull request を開いたり、再度開いたりしたとき、または pull request の head ブランチが更新されたときにワークフローが実行されます。 pull request レビュー、pull request レビュー コメント、または pull request コメントに関連するアクティビティには、代わりに [`pull_request_review`](#pull_request_review)、[`pull_request_review_comment`](#pull_request_review_comment)、または [`issue_comment`](#issue_comment) イベントを使います。 pull request API については、GraphQL API ドキュメントの「[Pull Request](/ja/enterprise-server@3.22/graphql/reference/pulls#object-pullrequest)」または「[Pull request 用 REST API エンドポイント](/ja/enterprise-server@3.22/rest/pulls)」をご覧ください。
このイベントの `GITHUB_SHA` が pull request マージ ブランチの最後のマージ コミットであることに注意してください。 pull request の head ブランチへの最後のコミットのコミット ID を取得する場合は、代わりに `github.event.pull_request.head.sha` を使います。 マージ ブランチの詳細については、「 [Pull Request](/ja/enterprise-server@3.22/pull-requests/reference/pull-requests#pull-request-refs-and-merge-branches)」を参照してください。
### マージ ブランチがワークフローに与える影響
オープンでマージ可能なプルリクエストの場合、`pull_request` イベントセットによりトリガーされたワークフローは、`GITHUB_REF` をマージブランチに設定します。
`actions/checkout`では既定で`GITHUB_REF`が使用されるため、マージ ブランチがチェックアウトされます。 CI テストは、ヘッド ブランチだけでなく、マージされた結果に対して実行されます。
* `GITHUB_REF` が `refs/pull/PULL_REQUEST_NUMBER/merge` に設定されている
* `GITHUB_SHA` は、マージ ブランチでのマージ コミットの SHA です
マージをシミュレートせずにヘッド ブランチコミットのみをテストするには、ワークフローで `github.event.pull_request.head.sha` を使用してヘッドブランチをチェックアウトします。
たとえば、pull request を開いたり再度開いたりしたときにワークフローを実行できます。
```yaml
on:
pull_request:
types: [opened, reopened]
```
イベント コンテキストを使って、ワークフロー内のジョブを実行するタイミングをさらに制御できます。 たとえば、このワークフローは pull request でレビューが要求されたときに実行されますが、`specific_review_requested` ジョブは `octo-team` によるレビューの要求時にのみ実行されます。
```yaml
on:
pull_request:
types: [review_requested]
jobs:
specific_review_requested:
runs-on: ubuntu-latest
if: ${{ github.event.requested_team.name == 'octo-team'}}
steps:
- run: echo 'A review from octo-team was requested'
```
### pull request の head またはベース ブランチに基づいて `pull_request` ワークフローを実行する
`branches` または `branches-ignore` フィルターを使って、特定のブランチを対象とする pull request でのみ実行するようにワークフローを構成できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore)」をご覧ください。
たとえば、このワークフローは、名前が `releases/` で始まるブランチを対象とする pull request を誰かが開いたときに実行されます。
```yaml
on:
pull_request:
types:
- opened
branches:
- 'releases/**'
```
> \[!NOTE]
> `branches` フィルターと `paths` フィルターの両方を使用する場合、ワークフローは両方のフィルターが満たされた場合にのみ実行されます。 たとえば、次のワークフローは、JavaScript (`.js`) ファイルへの変更を含むプル要求が、 `releases/`で始まるブランチで開かれた場合にのみ実行されます。
>
> ```yaml
> on:
> pull_request:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
(pull request のベース ブランチ名ではなく) pull request の head ブランチ名に基づいてジョブを実行するには、条件で `github.head_ref` コンテキストを使います。 たとえば、このワークフローは pull request が開かれるたびに実行されますが、pull request の head が `run_if` で始まる名前のブランチである場合にのみ `releases/` ジョブが実行されます。
```yaml
on:
pull_request:
types:
- opened
jobs:
run_if:
if: startsWith(github.head_ref, 'releases/')
runs-on: ubuntu-latest
steps:
- run: echo "The head of this PR starts with 'releases/'"
```
### pull request で変更されたファイルに基づいて `pull_request` ワークフローを実行する
また、pull request によって特定のファイルが変更されたときに実行するようにワークフローを構成することもできます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore)」をご覧ください。
たとえば、このワークフローは、pull request に JavaScript ファイル (`.js`) への変更が含まれているときに実行されます。
```yaml
on:
pull_request:
paths:
- '**.js'
```
> \[!NOTE]
> `branches` フィルターと `paths` フィルターの両方を使用する場合、ワークフローは両方のフィルターが満たされた場合にのみ実行されます。 たとえば、次のワークフローは、JavaScript (`.js`) ファイルへの変更を含むプル要求が、 `releases/`で始まるブランチで開かれた場合にのみ実行されます。
>
> ```yaml
> on:
> pull_request:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
### pull request がマージされたときに `pull_request` ワークフローが実行されるようにする
pull request がマージされると、pull request は自動的に閉じられます。 pull request のマージ時にワークフローを実行するには、イベントの `pull_request` 値を検査する条件とともにイベントの種類 `closed``merged` を使います。 たとえば、次のワークフローは、pull request が閉じるたびに実行されます。
`if_merged` ジョブは、pull request もマージされた場合にのみ実行されます。
```yaml
on:
pull_request:
types:
- closed
jobs:
if_merged:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
- run: |
echo The PR was merged
```
#### フォークされたリポジトリのワークフロー
デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 GitHub アクションは、フォークされたリポジトリの **\[アクション]** タブで有効にする必要があります。
`GITHUB_TOKEN` の例外を除き、ワークフローがフォークされたリポジトリからトリガーされた場合、シークレットはランナーに渡されません。
`GITHUB_TOKEN`には、フォークされたリポジトリからのプル要求の読み取り専用アクセス許可があります。 詳しくは、「[ワークフローでの認証に GITHUB\_TOKEN を使用する](/ja/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token)」をご覧ください。
#### フォークしたリポジトリのプルリクエストイベント
フォークされたリポジトリからベース リポジトリへのプル要求の場合、 GitHub は、 `pull_request`、 `issue_comment`、 `pull_request_review_comment`、 `pull_request_review`、および `pull_request_target` イベントをベース リポジトリに送信します。 フォークされたリポジトリでは、pull request イベントは発生しません。
フォークされたリポジトリからプライベート リポジトリへの pull request、ワークフローは有効になっている場合にのみ実行されます。「[リポジトリのGitHub Actions設定の管理](/ja/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories)」を参照してください。
> \[!NOTE]
> Dependabotプル要求によってトリガーされるワークフローは、フォークされたリポジトリからのワークフローと同様に扱われ、これらの制限も適用されます。
## `pull_request_comment` (`issue_comment` を使用)
プル リクエストの差分ではなくプル リクエストでコメントが作成、編修、削除されたときにワークフローを実行するには、[`issue_comment`](#issue_comment) イベントを使います。 pull request レビューまたは pull request レビュー コメントに関連するアクティビティには、[`pull_request_review`](#pull_request_review) または [`pull_request_review_comment`](#pull_request_review_comment) イベントを使います。
## `pull_request_review`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------- | ------------ | ------------ |
| [`pull_request_review`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#pull_request_review) | - `submitted`
- `edited`
- `dismissed` | | |
| `GITHUB_REF` ブランチでの最後のマージ コミット | PR マージ ブランチ `refs/pull/PULL_REQUEST_NUMBER/merge` | | |
> \[!NOTE]
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#pull_request_review) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
pull request レビューが送信、編集、または却下された場合にワークフローを実行します。 pull request レビューは、本文コメントと状態に加えて、pull request レビュー コメントのグループです。 pull request レビュー コメントまたは pull request コメントに関連するアクティビティには、代わりに [`pull_request_review_comment`](#pull_request_review_comment) または [`issue_comment`](#issue_comment) イベントを使います。 pull request レビュー API については、GraphQL API ドキュメントの「[Pull Request](/ja/enterprise-server@3.22/graphql/reference/pulls#object-pullrequest)」または「[Pull request 用 REST API エンドポイント](/ja/enterprise-server@3.22/rest/pulls#reviews)」をご覧ください。
たとえば、pull request レビューが `edited` または `dismissed` だったときにワークフローを実行できます。
```yaml
on:
pull_request_review:
types: [edited, dismissed]
```
### pull request が承認されたときにワークフローを実行する
pull request が承認されたときにワークフローを実行するには、種類 `submitted` の `pull_request_review` イベントを使ってワークフローをトリガーし、`github.event.review.state` プロパティを使ってレビューの状態を確認します。 たとえば、このワークフローは pull request レビューが送信されるたびに実行されますが、`approved` ジョブは、送信されたレビューが承認レビューである場合にのみ実行されます。
```yaml
on:
pull_request_review:
types: [submitted]
jobs:
approved:
if: github.event.review.state == 'approved'
runs-on: ubuntu-latest
steps:
- run: echo "This PR was approved"
```
#### フォークされたリポジトリのワークフロー
デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 GitHub アクションは、フォークされたリポジトリの **\[アクション]** タブで有効にする必要があります。
`GITHUB_TOKEN` の例外を除き、ワークフローがフォークされたリポジトリからトリガーされた場合、シークレットはランナーに渡されません。
`GITHUB_TOKEN`には、フォークされたリポジトリからのプル要求の読み取り専用アクセス許可があります。 詳しくは、「[ワークフローでの認証に GITHUB\_TOKEN を使用する](/ja/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token)」をご覧ください。
#### フォークしたリポジトリのプルリクエストイベント
フォークされたリポジトリからベース リポジトリへのプル要求の場合、 GitHub は、 `pull_request`、 `issue_comment`、 `pull_request_review_comment`、 `pull_request_review`、および `pull_request_target` イベントをベース リポジトリに送信します。 フォークされたリポジトリでは、pull request イベントは発生しません。
フォークされたリポジトリからプライベート リポジトリへの pull request、ワークフローは有効になっている場合にのみ実行されます。「[リポジトリのGitHub Actions設定の管理](/ja/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories)」を参照してください。
> \[!NOTE]
> Dependabotプル要求によってトリガーされるワークフローは、フォークされたリポジトリからのワークフローと同様に扱われ、これらの制限も適用されます。
## `pull_request_review_comment`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ------------ | ------------ |
| [`pull_request_review_comment`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#pull_request_review_comment) | - `created`
- `edited`
- `deleted` | | |
| `GITHUB_REF` ブランチでの最後のマージ コミット | PR マージ ブランチ `refs/pull/PULL_REQUEST_NUMBER/merge` | | |
> \[!NOTE]
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#pull_request_review_comment) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
pull request レビュー コメントが変更されたときにワークフローを実行します。 pull request レビュー コメントは、pull request の差分に関するコメントです。 pull request レビューまたは pull request コメントに関連するアクティビティには、代わりに [`pull_request_review`](#pull_request_review) または [`issue_comment`](#issue_comment) イベントを使います。 pull request レビュー コメント API については、GraphQL API ドキュメントの「[Pull Request](/ja/enterprise-server@3.22/graphql/reference/pulls#object-pullrequestreviewcomment)」または「[Pull request 用 REST API エンドポイント](/ja/enterprise-server@3.22/rest/pulls#comments)」をご覧ください。
たとえば、pull request レビュー コメントが `created` または `deleted` だったときにワークフローを実行できます。
```yaml
on:
pull_request_review_comment:
types: [created, deleted]
```
#### フォークされたリポジトリのワークフロー
デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 GitHub アクションは、フォークされたリポジトリの **\[アクション]** タブで有効にする必要があります。
`GITHUB_TOKEN` の例外を除き、ワークフローがフォークされたリポジトリからトリガーされた場合、シークレットはランナーに渡されません。
`GITHUB_TOKEN`には、フォークされたリポジトリからのプル要求の読み取り専用アクセス許可があります。 詳しくは、「[ワークフローでの認証に GITHUB\_TOKEN を使用する](/ja/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token)」をご覧ください。
#### フォークしたリポジトリのプルリクエストイベント
フォークされたリポジトリからベース リポジトリへのプル要求の場合、 GitHub は、 `pull_request`、 `issue_comment`、 `pull_request_review_comment`、 `pull_request_review`、および `pull_request_target` イベントをベース リポジトリに送信します。 フォークされたリポジトリでは、pull request イベントは発生しません。
フォークされたリポジトリからプライベート リポジトリへの pull request、ワークフローは有効になっている場合にのみ実行されます。「[リポジトリのGitHub Actions設定の管理](/ja/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories)」を参照してください。
> \[!NOTE]
> Dependabotプル要求によってトリガーされるワークフローは、フォークされたリポジトリからのワークフローと同様に扱われ、これらの制限も適用されます。
## `pull_request_target`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | ------------ |
| | | | |
| [`pull_request`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `locked`
- `unlocked`
- `milestoned`
- `demilestoned`
- `ready_for_review`
- `review_requested`
- `review_request_removed`
- `auto_merge_enabled`
- `auto_merge_disabled` | デフォルトブランチの直近のコミット | デフォルトブランチ |
| | | | |
> \[!NOTE]
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#pull_request) を参照してください。 既定では、ワークフローは、`pull_request_target` イベントのアクティビティの種類が `opened`、`synchronize`、または `reopened`にのみ実行されます。 さまざまなアクティビティの種類でワークフローをトリガーするには、`types` キーワードを使います。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
ワークフローのリポジトリ内の pull request のアクティビティが発生したときにワークフローを実行します。 たとえば、アクティビティの種類が指定されていない場合、pull request を開いたり、再度開いたりしたとき、または pull request の head ブランチが更新されたときにワークフローが実行されます。
このイベントは、ベース リポジトリの pull request既定ブランチの `pull_request` ベースのコンテキストで実行されます。 これで、リポジトリを変更したり、ワークフローで使うシークレットを盗んだりする可能性がある、pull request の head から安全ではないコードが実行されるのが避けられます。 このイベントを使うと、ワークフローでは、pull request に対するラベルやコメントなどの作業をフォークから行うことができます。 pull request からコードをビルドまたは実行する必要がある場合は、このイベントを使わないでください。
リポジトリのセキュリティを維持するため、特定のパターン (SHA に似ているものなど) と一致する名前を持つブランチからは、`pull_request_target` イベントでワークフローがトリガーされない場合があります。
> \[!WARNING]
> 信頼されていないコードが `pull_request_target` トリガーで実行されると、セキュリティ上の脆弱性が生じる可能性があります。 このような脆弱性として、キャッシュ ポイズニング、書き込み特権またはシークレットへの意図しないアクセス権の付与などがあります。 このトリガーを安全に使用する方法については、 [pull\_request\_target を安全に使用する](/ja/enterprise-server@3.22/actions/reference/security/securely-using-pull_request_target) を参照してください。 基になるリスクの詳細については、「[セキュリティで保護された使用に関するリファレンス](/ja/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout)」および「GitHub Security Lab」を参照してください。
たとえば、pull request が `assigned`、`opened`、`synchronize`、または `reopened` だったときにワークフローを実行できます。
```yaml
on:
pull_request_target:
types: [assigned, opened, synchronize, reopened]
```
### pull request の head またはベース ブランチに基づいて `pull_request_target` ワークフローを実行する
`branches` または `branches-ignore` フィルターを使って、特定のブランチを対象とする pull request でのみ実行するようにワークフローを構成できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore)」をご覧ください。
たとえば、このワークフローは、名前が `releases/` で始まるブランチを対象とする pull request を誰かが開いたときに実行されます。
```yaml
on:
pull_request_target:
types:
- opened
branches:
- 'releases/**'
```
> \[!NOTE]
> `branches` フィルターと `paths` フィルターの両方を使用する場合、ワークフローは両方のフィルターが満たされた場合にのみ実行されます。 たとえば、次のワークフローは、JavaScript (`.js`) ファイルへの変更を含むプル要求が、 `releases/`で始まるブランチで開かれた場合にのみ実行されます。
>
> ```yaml
> on:
> pull_request_target:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
(pull request のベース ブランチ名ではなく) pull request の head ブランチ名に基づいてジョブを実行するには、条件で `github.head_ref` コンテキストを使います。 たとえば、このワークフローは pull request が開かれるたびに実行されますが、pull request の head が `run_if` で始まる名前のブランチである場合にのみ `releases/` ジョブが実行されます。
```yaml
on:
pull_request_target:
types:
- opened
jobs:
run_if:
if: startsWith(github.head_ref, 'releases/')
runs-on: ubuntu-latest
steps:
- run: echo "The head of this PR starts with 'releases/'"
```
### pull request で変更されたファイルに基づいて `pull_request_target` ワークフローを実行する
`paths` または `paths-ignore` フィルターを使って、pull request によって特定のファイルが変更されたときに実行するようにワークフローを構成することもできます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore)」をご覧ください。
たとえば、このワークフローは、pull request に JavaScript ファイル (`.js`) への変更が含まれているときに実行されます。
```yaml
on:
pull_request_target:
paths:
- '**.js'
```
> \[!NOTE]
> `branches` フィルターと `paths` フィルターの両方を使用する場合、ワークフローは両方のフィルターが満たされた場合にのみ実行されます。 たとえば、次のワークフローは、JavaScript (`.js`) ファイルへの変更を含むプル要求が、 `releases/`で始まるブランチで開かれた場合にのみ実行されます。
>
> ```yaml
> on:
> pull_request_target:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
### pull request がマージされたときに `pull_request_target` ワークフローが実行されるようにする
pull request がマージされると、pull request は自動的に閉じられます。 pull request のマージ時にワークフローを実行するには、イベントの `pull_request_target` 値を検査する条件とともにイベントの種類 `closed``merged` を使います。 たとえば、次のワークフローは、pull request が閉じるたびに実行されます。
`if_merged` ジョブは、pull request もマージされた場合にのみ実行されます。
```yaml
on:
pull_request_target:
types:
- closed
jobs:
if_merged:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
- run: |
echo The PR was merged
```
## `push`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------ | ---------- | --------------------------------------------------------------------------------- | ------------ |
| [`push`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#push) | 該当なし | ヒント コミットが参照にプッシュされました。ブランチを削除すると、ワークフロー実行の SHA (およびその関連する参照) がリポジトリの既定のブランチに戻ります。 | 更新された ref |
> \[!NOTE]
>
> * GitHub Actionsで使用できる webhook ペイロードには、`added` オブジェクトの `removed`、`modified`、および `commit` 属性は含まれません。 完全な commit オブジェクトは、API を使って取得できます。 詳しくは、GraphQL API ドキュメントの「[コミット](/ja/enterprise-server@3.22/graphql/reference/commits#object-commit)」または「[コミット用の REST API エンドポイント](/ja/enterprise-server@3.22/rest/commits#get-a-commit)」をご覧ください。
> * 5,000 を超えるブランチが一度にプッシュされた場合、イベントは作成されません。 3 つ以上のタグが一度にプッシュされた場合、タグのイベントは作成されません。
コミットまたはタグをプッシュするとき、またはテンプレートからリポジトリを作成するときにワークフローを実行します。 これには、既定のブランチにマージされないワークフローが含まれます。 詳しくは、「[ワークフローをトリガーするイベント](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#running-your-workflow-only-when-a-push-to-specific-branches-occurs)」をご覧ください。
たとえば、`push` イベントが発生したときにワークフローを実行できます。
```yaml
on:
push
```
> \[!NOTE]
> `push` Webhook イベントによってワークフローの実行がトリガーされると、Actions UI の \[pushed by] フィールドには、作成者またはコミットしたユーザーではなく、プッシュしたユーザーのアカウントが表示されます。 一方、デプロイ キーによる SSH 認証を使って変更がリポジトリにプッシュされた場合は、\[プッシュ元] フィールドは、デプロイ キーがリポジトリに追加されたときにそれを確認したリポジトリ管理者になります。
### 特定のブランチへのプッシュが発生した場合にのみワークフローを実行する
`branches` または `branches-ignore` フィルターを使って、特定のブランチがプッシュされたときにのみ実行するようにワークフローを構成できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpushbranchestagsbranches-ignoretags-ignore)」をご覧ください。
たとえば、このワークフローは、`main` か、`releases/` で始まるブランチに誰かがプッシュしたときに実行されます。
```yaml
on:
push:
branches:
- 'main'
- 'releases/**'
```
> \[!NOTE]
> `branches` フィルターと `paths` フィルターの両方を使用する場合、ワークフローは両方のフィルターが満たされた場合にのみ実行されます。 たとえば、次のワークフローは、JavaScript (`.js`) ファイルへの変更を含むプッシュが、 `releases/`で始まる名前のブランチに対して行われた場合にのみ実行されます。
>
> ```yaml
> on:
> push:
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
### 特定のタグのプッシュが発生した場合にのみワークフローを実行する
`tags` または `tags-ignore` フィルターを使って、特定のタグがプッシュされたときにのみ実行するようにワークフローを構成できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpushbranchestagsbranches-ignoretags-ignore)」をご覧ください。
たとえば、このワークフローは、`v1.` で始まるタグを誰かがプッシュしたときに実行されます。
```yaml
on:
push:
tags:
- v1.**
```
### プッシュが特定のファイルに影響を与える場合にのみワークフローを実行する
`paths` または `paths-ignore` フィルターを使って、特定のファイルへのプッシュが発生したときに実行するようにワークフローを構成することができます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore)」をご覧ください。
たとえば、このワークフローは、誰かが JavaScript ファイル (`.js`) に変更をプッシュしたときに実行されます。
```yaml
on:
push:
paths:
- '**.js'
```
## `registry_package`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------------------------------------------- | ----------------------------- | -------------- | --------------------- |
| [`registry_package`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#package) | - `published`
- `updated` | 公開済みパッケージのコミット | 公開されたパッケージのブランチもしくはタグ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#registry_package) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
> * マルチアーキテクチャ コンテナー イメージをプッシュする場合、このイベントはマニフェストごとに 1 回発生するため、ワークフローが複数回トリガーされることがあります。 これを軽減し、実際のイメージ タグ情報を含むイベントに対してのみワークフロー ジョブを実行するには、条件を使用します。
>
> ```yaml
> jobs:
> job_name:
> if: $true
> ```
リポジトリで GitHub Packages に関連するアクティビティが発生したときにワークフローを実行します。 詳細については、 [GitHub Packages ドキュメントを参照してください](/ja/enterprise-server@3.22/packages)。
たとえば、新しいパッケージのバージョンが `published` になったらワークフローを実行できます。
```yaml
on:
registry_package:
types: [published]
```
## `release`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | --------------------- | -------------------------------- |
| [`release`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#release) | - `published`
- `unpublished`
- `created`
- `edited`
- `deleted`
- `prereleased`
- `released` | タグ付けされたリリースの中で最後のコミット | リリース`refs/tags/` の参照タグ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。 各アクティビティの種類については、 [Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#release) を参照してください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフローは、ドラフト リリースのアクティビティの種類 `created`、`edited`、または `deleted` ではトリガーされません。
> GitHub UI を使用してリリースを作成すると、リリースが自動的に下書きとして保存される場合があります。
> *
`prereleased` の種類は、ドラフト リリースから公開されたプレリリースではトリガーされませんが、`published` の種類はトリガーされます。 "安定した"\_と\_プレリリースのパブリッシュ時にワークフローを実行する場合は、`published` と `released` ではなく `prereleased` をサブスクライブします。
リポジトリのリリース アクティビティが発生したときにワークフローを実行します。 リリース API については、GraphQL API ドキュメントの「[リリース](/ja/enterprise-server@3.22/graphql/reference/releases#object-release)」または REST API ドキュメントの「[リリースとリリース資産の REST API エンドポイント](/ja/enterprise-server@3.22/rest/releases)」をご覧ください。
たとえば、リリースが `published` だったときにワークフローを実行できます。
```yaml
on:
release:
types: [published]
```
## `repository_dispatch`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------------------------------------------- | ---------- | ----------------- | ------------ |
| [repository\_dispatch](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#repository_dispatch) | カスタム | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
GitHub API を使用して、`repository_dispatch`の外部で発生するアクティビティのワークフローをトリガーする場合に、[](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#repository_dispatch)と呼ばれる Webhook イベントをトリガーできます。 詳しくは、「[リポジトリの REST API エンドポイント](/ja/enterprise-server@3.22/rest/repos/repos#create-a-repository-dispatch-event)」をご覧ください。
`repository_dispatch` イベントを作成する要求を行う場合は、アクティビティの種類を説明する `event_type` を指定する必要があります。 既定では、`repository_dispatch` のすべてのアクティビティの種類によってワークフローの実行がトリガーされます。
`types` キーワードを使うと、`event_type` Webhook ペイロードで特定の `repository_dispatch` 値が送信されたときに実行されるワークフローを制限できます。
```yaml
on:
repository_dispatch:
types: [test_result]
```
> \[!NOTE]
> `event_type` の値は 100 文字に制限されています。
`client_payload` パラメーターを使って送信するすべてのデータは、ワークフローの `github.event` コンテキストで使用できます。 たとえば、リポジトリ ディスパッチ イベントを作成するときにこの要求本文を送信する場合は、次のようになります。
```json
{
"event_type": "test_result",
"client_payload": {
"passed": false,
"message": "Error: timeout"
}
}
```
その後、次のようにワークフロー内のペイロードにアクセスできます。
```yaml
on:
repository_dispatch:
types: [test_result]
jobs:
run_if_failure:
if: ${{ !github.event.client_payload.passed }}
runs-on: ubuntu-latest
steps:
- env:
MESSAGE: ${{ github.event.client_payload.message }}
run: echo $MESSAGE
```
> \[!NOTE]
> \*
> `client_payload` の最上位レベルのプロパティの最大数は 10 です。
>
> * ペイロードには、最大 65,535 文字を含めることができます。
## `schedule`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------ | ---------- | ----------------- | ------------ |
| 該当なし | 該当なし | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
>
> * GitHub Actions のワークフローの実行によって高い負荷がかかっている間、`schedule` イベントが遅延する可能性があります。 高負荷の時間帯には、毎時の開始時点が含まれます。 負荷が十分に高い場合、キューに登録されたジョブの一部が削除される可能性があります。 遅延の可能性を減らすために、Ⅰ時間の中の別の時間帯に実行されるようワークフローをスケジューリングしてください。
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
> * スケジュールされたワークフローは、既定のブランチでのみ実行されます。
> * パブリックリポジトリでは、60日間にリポジトリにアクティビティがなかった場合、スケジュールされたワークフローは自動的に無効化されます。 無効にされたワークフローの再有効化については、「[ワークフローの無効化と有効化](/ja/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/disable-and-enable-workflows#enabling-a-workflow)」をご覧ください。
`schedule` イベントを使うと、スケジュールした時刻にワークフローをトリガーできます。
**Example:**
```yaml
on:
schedule:
- cron: "15 4,5 * * *"
```
[POSIX cron 構文](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07)を使用して、特定の時刻に実行するようにワークフローをスケジュールします。
既定では、スケジュールされたワークフローは UTC で実行されます。 必要に応じて、タイムゾーン対応のスケジュール設定のために [IANA タイムゾーン文字列](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) を使用してタイムゾーンを指定できます。 スケジュールされたワークフローは、既定のブランチの最新のコミットに対して実行されます。 スケジュールされたワークフローを実行できる最短の間隔は、5 分ごとに 1 回です。
> \[!NOTE]
> 夏時間 (DST) が適用されるタイムゾーンに `timezone` を設定するスケジュールの場合、春の時間進み (spring-forward) 切り替え中に、スキップされた時間のスケジュールされたワークフローは次の適切な時間に進みます。 たとえば、午前 2 時 30 分のスケジュールは午前 3 時に進みます。
クーロン構文では、スペースで分けられた 5 つのフィールドがあり、各フィールドは時間の単位を表わします。
```text
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
* * * * *
```
5 つのフィールドいずれにおいても、以下の演算子を使用できます:
| 演算子 | 説明 | 例 |
| --------------------------------------------------------- | ---------- | - |
| \* | 任意の値 | |
| `15 * * * *` は、毎日、毎時の15分に実行します。 | | |
| , | 値リストの区切り文字 | |
| `2,10 4,5 * * *`は、毎日4時台および5時台の2分および10分に実行します。 | | |
| - | 値の範囲 | |
| `30 4-6 * * *` は、開始から4時間目、5時間目、6時間目の30分に実行されます。 | | |
| / | ステップ値 | |
| `20/15 * * * *` は、20分から59分までの間、15分ごとに実行されます（20分、35分、50分）。 | | |
この例では、毎週月曜日から金曜日のアメリカ/New\_Yorkタイムゾーンで午前 5 時 30 分にワークフローを実行するようにトリガーします。
```yaml
on:
schedule:
- cron: '30 5 * * 1-5'
timezone: "America/New_York"
```
1 つのワークフローを、複数の `schedule` イベントでトリガーできます。
`schedule` コンテキストを通じて、ワークフローをトリガーした `github.event.schedule` イベントにアクセスします。 この例では、月曜日から木曜日までの 5:30 UTC および火曜日と木曜日の 17:30 UTC にワークフローの実行がトリガーされますが、月曜日と水曜日には `Not on Monday or Wednesday` ステップはスキップされます。
```yaml
on:
schedule:
- cron: '30 5 * * 1,3'
- cron: '30 5,17 * * 2,4'
jobs:
test_schedule:
runs-on: ubuntu-latest
steps:
- name: Not on Monday or Wednesday
if: github.event.schedule != '30 5 * * 1,3'
run: echo "This step will be skipped on Monday and Wednesday"
- name: Every time
run: echo "This step will always run"
```
> \[!NOTE]
> GitHub Actions では、標準以外の構文 `@yearly`、 `@monthly`、 `@weekly`、 `@daily`、 `@hourly`、および `@reboot`はサポートされていません。
[crontab guru](https://crontab.guru/) を使うと、cron 構文の生成および実行時間の確認に役立ちます。 作業の開始に役立つ [crontab guru のサンプル](https://crontab.guru/examples.html)一覧もあります。
### スケジュールされたワークフローの `actor`
特定のリポジトリ イベントによって、ワークフローに関連付けられている `actor` が変更されます。 たとえば、リポジトリの既定のブランチを変更する (それによってスケジュールされたワークフローを実行するブランチが変更される) ユーザーは、それらのスケジュールされたワークフローの `actor` になります。
スケジュールされたワークフローが非アクティブ化されている場合、リポジトリに対して `write` アクセス許可を持つユーザーがワークフローの `cron` スケジュールを変更するコミットを行うと、ワークフローは再アクティブ化され、そのユーザーはすべてのワークフロー実行に関連付けられた `actor` になります。
ワークフロー内のクーロン構文を最後に修正したユーザには、スケジュールされたワークフローの通知が送られます。 詳しくは、「[ワークフロー実行の通知](/ja/enterprise-server@3.22/actions/concepts/workflows-and-actions/notifications-for-workflow-runs)」をご覧ください。
> \[!NOTE]
> Enterprise Managed Usersを使用する企業の場合、スケジュールされたワークフローをトリガーするには、ワークフローに関連付けられている`actor`ユーザー アカウントの状態が現在アクティブである必要があります (つまり、中断も削除もされません)。
>
> * スケジュールされたワークフローに関連付けられた最後の `actor` が、 Enterprise Managed User ID プロバイダー (IdP) によってプロビジョニング解除された場合、スケジュールされたワークフローは実行されません。 ただし、最後の `actor`Enterprise Managed User が IdP によってプロビジョニング解除されておらず、企業内の特定の組織のメンバーとしてのみ削除されている場合でも、スケジュールされたワークフローは、そのユーザーが `actor`として設定された状態で実行されます。
> * 同様に、 Enterprise Managed Usersのない企業の場合、組織からユーザーを削除すると、そのユーザーが `actor` としてスケジュールされたワークフローを実行できなくなります。
> * したがって、*ユーザー アカウントの\_状態は、Enterprise Managed UserシナリオとEnterprise Managed User以外のシナリオの両方で重要であり、スケジュールされたワークフローが配置されている組織内のユーザーの\_メンバーシップの状態\_\_ではありません*。
## `status`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------- | ---------- | ----------------- | ------------ |
| [`status`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#status) | 該当なし | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
Git コミットの状態が変更されたときにワークフローを実行します。 たとえば、コミットは `error`、`failure`、`pending`、または `success` としてマークできます。 状態の変更に関する詳細を指定する場合は、[`check_run`](#check_run) イベントを使用できます。 コミット状態 API については、GraphQL API ドキュメントの「[コミット](/ja/enterprise-server@3.22/graphql/reference/commits#object-status)」または「[コミット用の REST API エンドポイント](/ja/enterprise-server@3.22/rest/commits#commit-statuses)」をご覧ください。
たとえば、`status` イベントが発生したときにワークフローを実行できます。
```yaml
on:
status
```
新しいコミット状態に基づいてワークフローでジョブを実行する場合は、`github.event.state` コンテキストを使用できます。 たとえば、次のワークフローはコミット状態が変更されたときにトリガーされますが、`if_error_or_failure` ジョブは新しいコミット状態が `error` または `failure`にのみ実行されます。
```yaml
on:
status
jobs:
if_error_or_failure:
runs-on: ubuntu-latest
if: >-
github.event.state == 'error' ||
github.event.state == 'failure'
steps:
- env:
DESCRIPTION: ${{ github.event.description }}
run: |
echo The status is error or failed: $DESCRIPTION
```
## `watch`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------- | ----------- | ----------------- | ------------ |
| [`watch`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#watch) | - `started` | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。
> `started` アクティビティの種類のみがサポートされていますが、今後追加されるアクティビティの種類が増える場合、アクティビティの種類を指定してもワークフロー固有の状態が維持されます。 各アクティビティの種類については、「[Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#watch)」をご覧ください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
ワークフローのリポジトリが Star 付きになったときにワークフローを実行します。 pull request API については、GraphQL API ドキュメントの「[Activity](/ja/enterprise-server@3.22/graphql/reference/activity#mutation-addstar)」または「[星付け用 REST API エンドポイント](/ja/enterprise-server@3.22/rest/activity/starring)」をご覧ください。
たとえば、誰かがリポジトリに star を付けたときにワークフローを実行できます。これは、Watch イベントのアクティビティの種類 `started` です。
```yaml
on:
watch:
types: [started]
```
## `workflow_call`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------ | ---------- | -------------- | -------------- |
| 呼び出し元ワークフローと同じ | 該当なし | 呼び出し元ワークフローと同じ | 呼び出し元ワークフローと同じ |
`workflow_call` は、別のワークフローからワークフローを呼び出すことができることを示すために使用されます。
`workflow_call` イベントを使ってワークフローがトリガーされると、呼び出し対象のワークフロー内のイベント ペイロードは、呼び出し元ワークフローからの同じイベント ペイロードになります。 詳しくは、「[ワークフローを再利用する](/ja/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows)」をご覧ください。
次の例では、別のワークフローから呼び出された場合にのみワークフローを実行します。
```yaml
on: workflow_call
```
## `workflow_dispatch`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------------------- | -------------------- | ------------ | ------------ |
| [workflow\_dispatch](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#workflow_dispatch) | 該当なし | | |
| `GITHUB_REF` ブランチまたはタグでの直近のコミット | ディスパッチを受信したブランチまたはタグ | | |
> \[!NOTE]
> ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
ワークフローを手動でトリガーできるようにするには、`workflow_dispatch` イベントを構成する必要があります。
GitHub API、GitHub CLI、またはGitHub UI を使用して、ワークフロー実行を手動でトリガーできます。 詳しくは、「[ワークフローの手動実行](/ja/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/manually-run-a-workflow)」をご覧ください。
```yaml
on: workflow_dispatch
```
### 入力の提供
カスタム定義の入力プロパティ、デフォルトの入力値、イベントに必要な入力をワークフローで直接設定できます。 イベントをトリガーするときは、`ref` と任意の `inputs` を指定できます。 ワークフローを実行すると、`inputs` コンテキスト内の入力値にアクセスできます。 詳しくは、「[コンテキスト リファレンス](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts)」をご覧ください。
> \[!NOTE]
>
> * ワークフローは、`github.event.inputs` コンテキスト内の入力も受け取ります。
> `inputs` コンテキストと `github.event.inputs` コンテキストの情報ですが、`inputs` コンテキストではブール値が文字列に変換されず、ブール値として保持されます。
> `choice` 型は文字列に解決され、1 つの選択可能なオプションです。
> *
`inputs`の最上位のプロパティの最大数は、10 です。
> \*
> `inputs` のペイロードの最大数は 65,535 文字です。
この例では、`logLevel`、`tags`、`environment` という名前の入力が定義されています。 これらの入力の値は、ワークフローに実行時に渡します。 次に、このワークフローでは、`inputs.logLevel`、`inputs.tags`、`inputs.environment` のコンテキスト プロパティを使って、値をログに出力します。
```yaml
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug
tags:
description: 'Test scenario tags'
required: false
type: boolean
environment:
description: 'Environment to run tests against'
type: environment
required: true
jobs:
log-the-inputs:
runs-on: ubuntu-latest
steps:
- run: |
echo "Log level: $LEVEL"
echo "Tags: $TAGS"
echo "Environment: $ENVIRONMENT"
env:
LEVEL: ${{ inputs.logLevel }}
TAGS: ${{ inputs.tags }}
ENVIRONMENT: ${{ inputs.environment }}
```
ブラウザーからこのワークフローを実行する場合は、ワークフローを実行する前に、必要な入力の値を手動で入力する必要があります。
スクリプトからワークフローを実行する場合や、 GitHub CLIを使用して入力を渡すこともできます。 次に例を示します。
```shell
gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging
```
詳細については、GitHub CLI の[](/ja/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/manually-run-a-workflow)情報を参照してください。
## `workflow_run`
| webhook イベントのペイロード | アクティビティの種類 | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------------------------------- | --------------------------------------------------- | ----------------- | ------------ |
| [`workflow_run`](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#workflow_run) | - `completed`
- `requested`
- `in_progress` | デフォルトブランチの直近のコミット | デフォルトブランチ |
> \[!NOTE]
> \*
> このイベントは、2つ以上の種類のアクティビティで起動されます。
> `requested` アクティビティの種類は、ワークフローの再実行時には発生しません。 各アクティビティの種類については、「[Webhook のイベントとペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#workflow_run)」をご覧ください。 既定では、すべてのアクティビティの種類で、このイベントに対して実行されるワークフローがトリガーされます。
> `types` キーワードを使うと、ワークフローの実行を特定の種類のアクティビティに限定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)」をご覧ください。
>
> * ワークフロー ファイルが既定のブランチに存在する場合にのみ、このイベントによってワークフローの実行がトリガーされます。
> * 3 つより多くのレベルのワークフローを連結するために、`workflow_run` を使うことはできません。 たとえば、最初のワークフロー `B` の実行後に (`F` から `A` という) 5 つのワークフローをトリガーして順番に実行しようとした場合 (つまり、`A` → `B` → `C` → `D` → `E` → `F`)、ワークフロー `E` と`F` は実行されません。
このイベントは、ワークフローの実行が要求されたか完了したときに発生します。 これで、別のワークフローの実行または完了に基づいてワークフローを実行できます。
`workflow_run` イベントによって開始されたワークフローでは、前のワークフローではできなかった場合でも、シークレットや書き込みトークンにアクセスできます。 これは、以前のワークフローが意図的に権限を与えられていない場合に役立ちますが、権限を与えられたアクションは後のワークフローで行わなければなりません。
> \[!WARNING]
> 信頼されていないコードが `workflow_run` トリガーで実行されると、セキュリティ上の脆弱性が生じる可能性があります。 このような脆弱性として、キャッシュ ポイズニング、書き込み特権またはシークレットへの意図しないアクセス権の付与などがあります。 詳細については、GitHub Enterprise Cloud ドキュメントの「[セキュリティで保護された使用に関するリファレンス](/ja/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout)」と、GitHub Security Lab Web サイトの「[pwn 要求を防ぐ](https://securitylab.github.com/research/github-actions-preventing-pwn-requests)」を参照してください。
この例では、ワークフローは個別の「Run Tests」ワークフローの完了後に実行されるように設定されています。
```yaml
on:
workflow_run:
workflows: [Run Tests]
types:
- completed
```
`workflows` イベントに複数の `workflow_run` を指定した場合、実行する必要があるワークフローは 1 つだけです。 たとえば、次のトリガーを持つワークフローは、"ステージング" ワークフローまたは "ラボ" ワークフローが完了するたびに実行されます。
```yaml
on:
workflow_run:
workflows: [Staging, Lab]
types:
- completed
```
### 別のワークフローの結果に基づいてワークフローを実行する
ワークフロー実行は、前のワークフローの結果に関係なくトリガーされます。 トリガーするワークフローの結果に基づいてジョブまたはステップを実行する場合は、`github.event.workflow_run.conclusion` プロパティで条件を使用できます。 たとえば、このワークフローは、"Build" という名前のワークフローが完了するたびに実行されますが、`on-success` ジョブは、"Build" ワークフローが成功した場合にのみ実行され、`on-failure` ジョブは "Build" ワークフローが失敗した場合にのみ実行されます。
```yaml
on:
workflow_run:
workflows: [Build]
types: [completed]
jobs:
on-success:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
- run: echo 'The triggering workflow passed'
on-failure:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'failure' }}
steps:
- run: echo 'The triggering workflow failed'
```
### ブランチに基づいて実行するワークフローを制限する
`branches` または `branches-ignore` フィルターを使って、ワークフローをトリガーするために、トリガーするワークフローで実行する必要があるブランチを指定できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_runbranchesbranches-ignore)」をご覧ください。 たとえば、次のトリガーを持つワークフローは、名前が `Build` のブランチで `canary` という名前のワークフローが実行される場合にのみ実行されます。
```yaml
on:
workflow_run:
workflows: [Build]
types: [requested]
branches: [canary]
```
### トリガーするワークフローからデータを使う
ワークフローをトリガーしたワークフローに対応する [`workflow_run`イベント ペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#workflow_run)にアクセスできます。 たとえば、トリガーするワークフローによって成果物が生成される場合、`workflow_run` イベントでトリガーされたワークフローからこれらの成果物にアクセスできます。
次のワークフローでは、データを成果物としてアップロードします。 (この簡略化された例では、データは pull request 番号です)。
```yaml
name: Upload data
on:
pull_request:
jobs:
upload:
runs-on: ubuntu-latest
steps:
- name: Save PR number
env:
PR_NUMBER: ${{ github.event.number }}
run: |
mkdir -p ./pr
echo $PR_NUMBER > ./pr/pr_number
- uses: actions/upload-artifact@v3
with:
name: pr_number
path: pr/
```
上記のワークフローの実行が完了すると、次のワークフローの実行がトリガーされます。 次のワークフローでは、 `github.event.workflow_run` コンテキストと actions/download-artifact\@v3 アクションを使用して、上記のワークフローによってアップロードされた成果物をダウンロードし、その番号が成果物としてアップロードされた pull request にコメントを付けます。
```yaml
name: Use the data
on:
workflow_run:
workflows: [Upload data]
types:
- completed
jobs:
download:
runs-on: ubuntu-latest
steps:
- name: 'Download artifact'
uses: actions/download-artifact@v3
with:
name: pr_number
# do not extract in the workspace dir that may contain executable scripts
path: ${{ runner.temp }}/artifacts
run-id: ${{ github.event.workflow_run.id }}
github-token: ${{ secrets.GITHUB_TOKEN }}
- name: 'Comment on PR'
uses: actions/github-script@v8
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
const fs = require('fs');
const path = require('path');
const temp = '${{ runner.temp }}/artifacts';
const issue_number_raw = fs.readFileSync(path.join(temp, 'pr_number'), 'utf8').trim();
const issue_number = Number(issue_number_raw);
if (!Number.isInteger(issue_number)) {
throw new Error(`Invalid PR number in pr_number artifact: "${issue_number_raw}"`);
}
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue_number,
body: 'Thank you for the PR!'
});
```