{"meta":{"title":"触发工作流的事件","intro":"可以配置工作流，使其在GitHub上发生特定活动时、在计划的时间运行，或在GitHub之外发生事件时启动。","product":"GitHub Actions","breadcrumbs":[{"href":"/zh/actions","title":"GitHub Actions"},{"href":"/zh/actions/reference","title":"参考"},{"href":"/zh/actions/reference/workflows-and-actions","title":"工作流和操作"},{"href":"/zh/actions/reference/workflows-and-actions/events-that-trigger-workflows","title":"触发工作流的事件"}],"documentType":"article"},"body":"# 触发工作流的事件\n\n可以配置工作流，使其在GitHub上发生特定活动时、在计划的时间运行，或在GitHub之外发生事件时启动。\n\n\n## About events that trigger workflows\n\nWorkflow triggers are events that cause a workflow to run. For more information about how to use workflow triggers, see [Triggering a workflow](/en/actions/using-workflows/triggering-a-workflow).\n\nSome events have multiple activity types. For these events, you can specify which activity types will trigger a workflow run. For more information about what each activity type means, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads).\n\n> \\[!NOTE]\n> Not all webhook events trigger workflows.\n\n## `branch_protection_rule`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | ----------------------------- | -------------- |\n| [`branch_protection_rule`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#branch_protection_rule) | - `created`
- `edited`
- `deleted` | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#branch_protection_rule). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nRuns your workflow when branch protection rules in the workflow repository are changed. For more information about branch protection rules, see [About protected branches](/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches). For information about the branch protection rule APIs, see [Objects](/en/graphql/reference/objects#branchprotectionrule) in the GraphQL API documentation or [REST API endpoints for branches and their settings](/en/rest/branches).\n\nFor example, you can run a workflow when a branch protection rule has been `created` or `deleted`:\n\n```yaml\non:\n branch_protection_rule:\n types: [created, deleted]\n```\n\n## `check_run`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ----------------------------- | -------------- |\n| [`check_run`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#check_run) | - `created`
- `rerequested`
- `completed`
- `requested_action` | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#check_run). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n> * To prevent recursive workflows, this event does not trigger workflows if the check run's check suite was created by GitHub Actions or if the check suite's head SHA is associated with GitHub Actions.\n\nRuns your workflow when activity related to a check run occurs. A check run is an individual test that is part of a check suite. For information, see [Using the REST API to interact with checks](/en/rest/guides/using-the-rest-api-to-interact-with-checks). For information about the check run APIs, see [Objects](/en/graphql/reference/objects#checkrun) in the GraphQL API documentation or [REST API endpoints for check runs](/en/rest/checks/runs).\n\nFor example, you can run a workflow when a check run has been `rerequested` or `completed`.\n\n```yaml\non:\n check_run:\n types: [rerequested, completed]\n```\n\n## `check_suite`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ----------------------------------------------------------------------------------------- | -------------- | ----------------------------- | -------------- |\n| [`check_suite`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#check_suite) | - `completed` | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#check_suite). Although only the `completed` activity type is supported, specifying the activity type will keep your workflow specific if more activity types are added in the future. By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n> * To prevent recursive workflows, this event does not trigger workflows if the check suite was created by GitHub Actions or if the check suite's head SHA is associated with GitHub Actions.\n\nRuns your workflow when check suite activity occurs. A check suite is a collection of the check runs created for a specific commit. Check suites summarize the status and conclusion of the check runs that are in the suite. For information, see [Using the REST API to interact with checks](/en/rest/guides/using-the-rest-api-to-interact-with-checks). For information about the check suite APIs, see [Objects](/en/graphql/reference/objects#checksuite) in the GraphQL API documentation or [REST API endpoints for check suites](/en/rest/checks/suites).\n\nFor example, you can run a workflow when a check suite has been `completed`.\n\n```yaml\non:\n check_suite:\n types: [completed]\n```\n\n## `create`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------- | -------------- | ---------------------------------------- | --------------------- |\n| [`create`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#create) | Not applicable | Last commit on the created branch or tag | Branch or tag created |\n\n> \\[!NOTE]\n> An event will not be created when you create more than three tags at once.\n\nRuns your workflow when someone creates a Git reference (Git branch or tag) in the workflow's repository. For information about the APIs to create a Git reference, see [Mutations](/en/graphql/reference/mutations#createref) in the GraphQL API documentation or [REST API endpoints for Git references](/en/rest/git/refs#create-a-reference).\n\nFor example, you can run a workflow when the `create` event occurs.\n\n```yaml\non:\n create\n```\n\n## `delete`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------- | -------------- | ----------------------------- | -------------- |\n| [`delete`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#delete) | Not applicable | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n> * An event will not be created when you delete more than three tags at once.\n\nRuns your workflow when someone deletes a Git reference (Git branch or tag) in the workflow's repository. For information about the APIs to delete a Git reference, see [Mutations](/en/graphql/reference/mutations#deleteref) in the GraphQL API documentation or [REST API endpoints for Git references](/en/rest/git/refs#delete-a-reference).\n\nFor example, you can run a workflow when the `delete` event occurs.\n\n```yaml\non:\n delete\n```\n\n## `deployment`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------------------------------------------------------------------------- | -------------- | --------------------- | ----------------------------------------------------------------- |\n| [`deployment`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment) | Not applicable | Commit to be deployed | Branch or tag to be deployed (empty if created with a commit SHA) |\n\nRuns your workflow when someone creates a deployment in the workflow's repository. Deployments created with a commit SHA may not have a Git ref. For information about the APIs to create a deployment, see [Mutations](/en/graphql/reference/mutations#createdeployment) in the GraphQL API documentation or [REST API endpoints for repositories](/en/rest/repos#deployments).\n\nFor example, you can run a workflow when the `deployment` event occurs.\n\n```yaml\non:\n deployment\n```\n\n## `deployment_status`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ----------------------------------------------------------------------------------------------------- | -------------- | --------------------- | ---------------------------------------------- |\n| [`deployment_status`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment_status) | Not applicable | Commit to be deployed | Branch or tag to be deployed (empty if commit) |\n\n> \\[!NOTE]\n> When a deployment status's state is set to `inactive`, a workflow run will not be triggered.\n\nRuns your workflow when a third party provides a deployment status. Deployments created with a commit SHA may not have a Git ref. For information about the APIs to create a deployment status, see [Mutations](/en/graphql/reference/mutations#createdeploymentstatus) in the GraphQL API documentation or [REST API endpoints for deployments](/en/rest/deployments#create-a-deployment-status).\n\nFor example, you can run a workflow when the `deployment_status` event occurs.\n\n```yaml\non:\n deployment_status\n```\n\n## `discussion`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | -------------- |\n| [`discussion`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#discussion) | - `created`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `category_changed`
- `answered`
- `unanswered` | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#discussion). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n> * Webhook events for GitHub Discussions are currently in public preview and subject to change.\n\nRuns your workflow when a discussion in the workflow's repository is created or modified. For activity related to comments on a discussion, use the [`discussion_comment`](#discussion_comment) event. For more information about discussions, see [About discussions](/en/discussions/collaborating-with-your-community-using-discussions/about-discussions). For information about the GraphQL API, see [Objects](/en/graphql/reference/objects#discussion).\n\nFor example, you can run a workflow when a discussion has been `created`, `edited`, or `answered`.\n\n```yaml\non:\n discussion:\n types: [created, edited, answered]\n```\n\n## `discussion_comment`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | ----------------------------- | -------------- |\n| [`discussion_comment`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#discussion_comment) | - `created`
- `edited`
- `deleted`
| Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#discussion_comment). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n> * Webhook events for GitHub Discussions are currently in public preview and subject to change.\n\nRuns your workflow when a comment on a discussion in the workflow's repository is created or modified. For activity related to a discussion as opposed to comments on the discussion, use the [`discussion`](#discussion) event. For more information about discussions, see [About discussions](/en/discussions/collaborating-with-your-community-using-discussions/about-discussions). For information about the GraphQL API, see [Objects](/en/graphql/reference/objects#discussion).\n\nFor example, you can run a workflow when a discussion comment has been `created` or `deleted`.\n\n```yaml\non:\n discussion_comment:\n types: [created, deleted]\n```\n\n## `fork`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------------------------------------------------------------- | -------------- | ----------------------------- | -------------- |\n| [`fork`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#fork) | Not applicable | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n> This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nRuns your workflow when someone forks a repository. For information about the REST API, see [REST API endpoints for forks](/en/rest/repos/forks#create-a-fork).\n\nFor example, you can run a workflow when the `fork` event occurs.\n\n```yaml\non:\n fork\n```\n\n## `gollum`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------- | -------------- | ----------------------------- | -------------- |\n| [`gollum`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#gollum) | Not applicable | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n> This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nRuns your workflow when someone creates or updates a Wiki page. For more information, see [About wikis](/en/communities/documenting-your-project-with-wikis/about-wikis).\n\nFor example, you can run a workflow when the `gollum` event occurs.\n\n```yaml\non:\n gollum\n```\n\n## `image_version`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------- | -------------- | ----------------------------- | -------------- |\n| Not applicable | Not applicable | Last commit on default branch | Default branch |\n\nRuns your workflow when a new version of a specified image becomes available for use. This event is typically triggered after a successful image version creation, allowing you to automate actions such as deployment or notifications in response to new image versions.\n\nThis event supports glob patterns for both image names and versions. The example below triggers when a new image version matches any of the specified name and version combinations. For example, `[\"MyNewImage\", 1.0.0]`, `[\"MyNewImage\", 2.53.0]`, `[\"MyOtherImage\", 1.0.0]`, and `[\"MyOtherImage\", 2.0.0]`.\n\n```yaml\non:\n image_version:\n names:\n - \"MyNewImage\"\n - \"MyOtherImage\"\n versions:\n - 1.*\n - 2.*\n```\n\n## `issue_comment`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------------------------------------------------------------------------------- | ----------------------------------------------- | ----------------------------- | -------------- |\n| [`issue_comment`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#issue_comment) | - `created`
- `edited`
- `deleted`
| Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#issue_comment). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nRuns your workflow when an issue or pull request comment is created, edited, or deleted. For information about the issue comment APIs, see [Objects](/en/graphql/reference/objects#issuecomment) in the GraphQL API documentation or [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#issue_comment) in the REST API documentation.\n\nFor example, you can run a workflow when an issue or pull request comment has been `created` or `deleted`.\n\n```yaml\non:\n issue_comment:\n types: [created, deleted]\n```\n\n### `issue_comment` on issues only or pull requests only\n\nThe `issue_comment` event occurs for comments on both issues and pull requests. You can use the `github.event.issue.pull_request` property in a conditional to take different action depending on whether the triggering object was an issue or pull request.\n\nFor example, this workflow will run the `pr_commented` job only if the `issue_comment` event originated from a pull request. It will run the `issue_commented` job only if the `issue_comment` event originated from an issue.\n\n```yaml\non: issue_comment\n\njobs:\n pr_commented:\n # This job only runs for pull request comments\n name: PR comment\n if: ${{ github.event.issue.pull_request }}\n runs-on: ubuntu-latest\n steps:\n - run: |\n echo A comment on PR $NUMBER\n env:\n NUMBER: ${{ github.event.issue.number }}\n\n issue_commented:\n # This job only runs for issue comments\n name: Issue comment\n if: ${{ !github.event.issue.pull_request }}\n runs-on: ubuntu-latest\n steps:\n - run: |\n echo A comment on issue $NUMBER\n env:\n NUMBER: ${{ github.event.issue.number }}\n```\n\n## `issues`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- | -------------- |\n| [`issues`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#issues) | - `opened`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `closed`
- `reopened`
- `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `milestoned`
- `demilestoned`
- `typed`
- `untyped` | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#issues). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nRuns your workflow when an issue in the workflow's repository is created or modified. For activity related to comments in an issue, use the [`issue_comment`](#issue_comment) event. For more information about issues, see [About issues](/en/issues/tracking-your-work-with-issues/about-issues). For information about the issue APIs, see [Objects](/en/graphql/reference/objects#issue) in the GraphQL API documentation or [REST API endpoints for issues](/en/rest/issues).\n\nFor example, you can run a workflow when an issue has been `opened`, `edited`, or `milestoned`.\n\n```yaml\non:\n issues:\n types: [opened, edited, milestoned]\n```\n\n## `label`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ----------------------------------------------------------------------------- | ----------------------------------------------- | ----------------------------- | -------------- |\n| [`label`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#label) | - `created`
- `edited`
- `deleted`
| Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#label). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nRuns your workflow when a label in your workflow's repository is created or modified. For more information about labels, see [Managing labels](/en/issues/using-labels-and-milestones-to-track-work/managing-labels). For information about the label APIs, see [Objects](/en/graphql/reference/objects#label) in the GraphQL API documentation or [REST API endpoints for labels](/en/rest/issues/labels).\n\nIf you want to run your workflow when a label is added to or removed from an issue, pull request, or discussion, use the `labeled` or `unlabeled` activity types for the [`issues`](#issues), [`pull_request`](#pull_request), [`pull_request_target`](#pull_request_target), or [`discussion`](#discussion) events instead.\n\nFor example, you can run a workflow when a label has been `created` or `deleted`.\n\n```yaml\non:\n label:\n types: [created, deleted]\n```\n\n## `merge_group`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ----------------------------------------------------------------------------------------- | ------------------ | ---------------------- | ---------------------- |\n| [`merge_group`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#merge_group) | `checks_requested` | SHA of the merge group | Ref of the merge group |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. Although only the `checks_requested` activity type is supported, specifying the activity type will keep your workflow specific if more activity types are added in the future. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#merge_group). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * If your repository uses GitHub Actions to perform required checks on pull requests in your repository, you need to update the workflows to include the `merge_group` event as an additional trigger. Otherwise, status checks will not be triggered when you add a pull request to a merge queue. The merge will fail as the required status check will not be reported. The `merge_group` event is separate from the `pull_request` and `push` events.\n\nRuns your workflow when a pull request is added to a merge queue, which adds the pull request to a merge group. For more information see [Merging a pull request with a merge queue](/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue).\n\nFor example, you can run a workflow when the `checks_requested` activity has occurred.\n\n```yaml\non:\n pull_request:\n branches: [ \"main\" ]\n merge_group:\n types: [checks_requested]\n```\n\n## `milestone`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ----------------------------- | -------------- |\n| [`milestone`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#milestone) | - `created`
- `closed`
- `opened`
- `edited`
- `deleted`
| Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#milestone). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nRuns your workflow when a milestone in the workflow's repository is created or modified. For more information about milestones, see [About milestones](/en/issues/using-labels-and-milestones-to-track-work/about-milestones). For information about the milestone APIs, see [Objects](/en/graphql/reference/objects#milestone) in the GraphQL API documentation or [REST API endpoints for milestones](/en/rest/issues/milestones).\n\nIf you want to run your workflow when an issue is added to or removed from a milestone, use the `milestoned` or `demilestoned` activity types for the [`issues`](#issues) event instead.\n\nFor example, you can run a workflow when a milestone has been `opened` or `deleted`.\n\n```yaml\non:\n milestone:\n types: [opened, deleted]\n```\n\n## `page_build`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------------------------------------------------------------------------- | -------------- | ----------------------------- | -------------- |\n| [`page_build`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#page_build) | Not applicable | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n> This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nRuns your workflow when someone pushes to a branch that is the publishing source for GitHub Pages, if GitHub Pages is enabled for the repository. For more information about GitHub Pages publishing sources, see [Configuring a publishing source for your GitHub Pages site](/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site). For information about the REST API, see [REST API endpoints for repositories](/en/rest/repos#pages).\n\nFor example, you can run a workflow when the `page_build` event occurs.\n\n```yaml\non:\n page_build\n```\n\n## `public`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------- | -------------- | ----------------------------- | -------------- |\n| [`public`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#public) | Not applicable | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n> This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nRuns your workflow when your workflow's repository changes from private to public. For information about the REST API, see [REST API endpoints for repositories](/en/rest/repos#edit).\n\nFor example, you can run a workflow when the `public` event occurs.\n\n```yaml\non:\n public\n```\n\n## `pull_request`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | ----------------------------------------------------- |\n| [`pull_request`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `locked`
- `unlocked`
- `enqueued`
- `dequeued`
- `milestoned`
- `demilestoned`
- `ready_for_review`
- `review_requested`
- `review_request_removed`
- `auto_merge_enabled`
- `auto_merge_disabled` | Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/PULL_REQUEST_NUMBER/merge` |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request). By default, a workflow only runs when a `pull_request` event's activity type is `opened`, `synchronize`, or `reopened`. To trigger workflows by different activity types, use the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * Workflows will not run on `pull_request` activity if the pull request has a merge conflict. The merge conflict must be resolved first. Conversely, workflows with the `pull_request_target` event will run even if the pull request has a merge conflict. Before using the `pull_request_target` trigger, you should be aware of the security risks. For more information, see [`pull_request_target`](#pull_request_target).\n> * The `pull_request` webhook event payload is empty for merged pull requests and pull requests that come from forked repositories.\n> * The value of `GITHUB_REF` varies for a closed pull request depending on whether the pull request has been merged or not. If a pull request was closed but not merged, it will be `refs/pull/PULL_REQUEST_NUMBER/merge`. If a pull request was closed as a result of being merged, it will be the fully qualified `ref` of the branch it was merged into, for example `/refs/heads/main`.\n\nRuns your workflow when activity on a pull request in the workflow's repository occurs. For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated. For activity related to pull request reviews, pull request review comments, or pull request comments, use the [`pull_request_review`](#pull_request_review), [`pull_request_review_comment`](#pull_request_review_comment), or [`issue_comment`](#issue_comment) events instead. For information about the pull request APIs, see [Objects](/en/graphql/reference/objects#pullrequest) in the GraphQL API documentation or [REST API endpoints for pull requests](/en/rest/pulls).\n\nNote that `GITHUB_SHA` for this event is the last merge commit of the pull request merge branch. If you want to get the commit ID for the last commit to the head branch of the pull request, use `github.event.pull_request.head.sha` instead. For more information about merge branches, see [About pull requests](/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches).\n\n### How the merge branch affects your workflow\n\nFor open, mergeable pull requests, workflows triggered by the `pull_request` event set `GITHUB_REF` to the merge branch. Because `actions/checkout` uses `GITHUB_REF` by default, it checks out the merge branch. Your CI tests run against the merged result, not just the head branch alone:\n\n* `GITHUB_REF` is set to `refs/pull/PULL_REQUEST_NUMBER/merge`\n* `GITHUB_SHA` is the SHA of the merge commit on the merge branch\n\nTo test only the head branch commits without simulating a merge, check out the head branch using `github.event.pull_request.head.sha` in your workflow.\n\nFor example, you can run a workflow when a pull request has been opened or reopened.\n\n```yaml\non:\n pull_request:\n types: [opened, reopened]\n```\n\nYou can use the event context to further control when jobs in your workflow will run. For example, this workflow will run when a review is requested on a pull request, but the `specific_review_requested` job will only run when a review by `octo-team` is requested.\n\n```yaml\non:\n pull_request:\n types: [review_requested]\njobs:\n specific_review_requested:\n runs-on: ubuntu-latest\n if: ${{ github.event.requested_team.name == 'octo-team'}}\n steps:\n - run: echo 'A review from octo-team was requested'\n```\n\n### Running your `pull_request` workflow based on the head or base branch of a pull request\n\nYou can use the `branches` or `branches-ignore` filter to configure your workflow to only run on pull requests that target specific branches. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore).\n\nFor example, this workflow will run when someone opens a pull request that targets a branch whose name starts with `releases/`:\n\n```yaml\non:\n pull_request:\n types:\n - opened\n branches:\n - 'releases/**'\n```\n\n> \\[!NOTE]\n> If you use both the `branches` filter and the `paths` filter, the workflow will only run when both filters are satisfied. For example, the following workflow will only run when a pull request that includes a change to a JavaScript (`.js`) file is opened on a branch whose name starts with `releases/`:\n>\n> ```yaml\n> on:\n> pull_request:\n> types:\n> - opened\n> branches:\n> - 'releases/**'\n> paths:\n> - '**.js'\n> ```\n\nTo run a job based on the pull request's head branch name (as opposed to the pull request's base branch name), use the `github.head_ref` context in a conditional. For example, this workflow will run whenever a pull request is opened, but the `run_if` job will only execute if the head of the pull request is a branch whose name starts with `releases/`:\n\n```yaml\non:\n pull_request:\n types:\n - opened\njobs:\n run_if:\n if: startsWith(github.head_ref, 'releases/')\n runs-on: ubuntu-latest\n steps:\n - run: echo \"The head of this PR starts with 'releases/'\"\n```\n\n### Running your `pull_request` workflow based on files changed in a pull request\n\nYou can also configure your workflow to run when a pull request changes specific files. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore).\n\nFor example, this workflow will run when a pull request includes a change to a JavaScript file (`.js`):\n\n```yaml\non:\n pull_request:\n paths:\n - '**.js'\n```\n\n> \\[!NOTE]\n> If you use both the `branches` filter and the `paths` filter, the workflow will only run when both filters are satisfied. For example, the following workflow will only run when a pull request that includes a change to a JavaScript (`.js`) file is opened on a branch whose name starts with `releases/`:\n>\n> ```yaml\n> on:\n> pull_request:\n> types:\n> - opened\n> branches:\n> - 'releases/**'\n> paths:\n> - '**.js'\n> ```\n\n### Running your `pull_request` workflow when a pull request merges\n\nWhen a pull request merges, the pull request is automatically closed. To run a workflow when a pull request merges, use the `pull_request` `closed` event type along with a conditional that checks the `merged` value of the event. For example, the following workflow will run whenever a pull request closes. The `if_merged` job will only run if the pull request was also merged.\n\n```yaml\non:\n pull_request:\n types:\n - closed\n\njobs:\n if_merged:\n if: github.event.pull_request.merged == true\n runs-on: ubuntu-latest\n steps:\n - run: |\n echo The PR was merged\n```\n\n#### Workflows in forked repositories\n\nWorkflows don't run in forked repositories by default. You must enable GitHub Actions in the **Actions** tab of the forked repository.\n\nWith the exception of `GITHUB_TOKEN`, secrets are not passed to the runner when a workflow is triggered from a forked repository. The `GITHUB_TOKEN` has read-only permissions in pull requests from forked repositories. For more information, see [Use GITHUB\\_TOKEN for authentication in workflows](/en/actions/security-guides/automatic-token-authentication).\n\n#### Pull request events for forked repositories\n\nFor pull requests from a forked repository to the base repository, GitHub sends the `pull_request`, `issue_comment`, `pull_request_review_comment`, `pull_request_review`, and `pull_request_target` events to the base repository. No pull request events occur on the forked repository.\n\nWhen a first-time contributor submits a pull request to a public repository, a maintainer with write access may need to approve running workflows on the pull request. For more information, see [Approving workflow runs from forks](/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).\n\nFor pull requests from a forked repository to a private repository, workflows only run when they are enabled, see [Managing GitHub Actions settings for a repository](/en/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).\n\n> \\[!NOTE]\n> Workflows triggered by Dependabot pull requests are treated as though they are from a forked repository, and are also subject to these restrictions.\n\n## `pull_request_comment` (use `issue_comment`)\n\nTo run your workflow when a comment on a pull request (not on a pull request's diff) is created, edited, or deleted, use the [`issue_comment`](#issue_comment) event. For activity related to pull request reviews or pull request review comments, use the [`pull_request_review`](#pull_request_review) or [`pull_request_review_comment`](#pull_request_review_comment) events.\n\n## `pull_request_review`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | -------------------------------------------- | ----------------------------------------------------- |\n| [`pull_request_review`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request_review) | - `submitted`
- `edited`
- `dismissed` | Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/PULL_REQUEST_NUMBER/merge` |\n\n> \\[!NOTE]\n> More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request_review). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n\nRuns your workflow when a pull request review is submitted, edited, or dismissed. A pull request review is a group of pull request review comments in addition to a body comment and a state. For activity related to pull request review comments or pull request comments, use the [`pull_request_review_comment`](#pull_request_review_comment) or [`issue_comment`](#issue_comment) events instead. For information about the pull request review APIs, see [Objects](/en/graphql/reference/objects#pullrequest) in the GraphQL API documentation or [REST API endpoints for pull requests](/en/rest/pulls#reviews).\n\nFor example, you can run a workflow when a pull request review has been `edited` or `dismissed`.\n\n```yaml\non:\n pull_request_review:\n types: [edited, dismissed]\n```\n\n### Running a workflow when a pull request is approved\n\nTo run your workflow when a pull request has been approved, you can trigger your workflow with the `submitted` type of `pull_request_review` event, then check the review state with the `github.event.review.state` property. For example, this workflow will run whenever a pull request review is submitted, but the `approved` job will only run if the submitted review is an approving review:\n\n```yaml\non:\n pull_request_review:\n types: [submitted]\n\njobs:\n approved:\n if: github.event.review.state == 'approved'\n runs-on: ubuntu-latest\n steps:\n - run: echo \"This PR was approved\"\n```\n\n#### Workflows in forked repositories\n\nWorkflows don't run in forked repositories by default. You must enable GitHub Actions in the **Actions** tab of the forked repository.\n\nWith the exception of `GITHUB_TOKEN`, secrets are not passed to the runner when a workflow is triggered from a forked repository. The `GITHUB_TOKEN` has read-only permissions in pull requests from forked repositories. For more information, see [Use GITHUB\\_TOKEN for authentication in workflows](/en/actions/security-guides/automatic-token-authentication).\n\n#### Pull request events for forked repositories\n\nFor pull requests from a forked repository to the base repository, GitHub sends the `pull_request`, `issue_comment`, `pull_request_review_comment`, `pull_request_review`, and `pull_request_target` events to the base repository. No pull request events occur on the forked repository.\n\nWhen a first-time contributor submits a pull request to a public repository, a maintainer with write access may need to approve running workflows on the pull request. For more information, see [Approving workflow runs from forks](/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).\n\nFor pull requests from a forked repository to a private repository, workflows only run when they are enabled, see [Managing GitHub Actions settings for a repository](/en/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).\n\n> \\[!NOTE]\n> Workflows triggered by Dependabot pull requests are treated as though they are from a forked repository, and are also subject to these restrictions.\n\n## `pull_request_review_comment`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | -------------------------------------------- | ----------------------------------------------------- |\n| [`pull_request_review_comment`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request_review_comment) | - `created`
- `edited`
- `deleted` | Last merge commit on the `GITHUB_REF` branch | PR merge branch `refs/pull/PULL_REQUEST_NUMBER/merge` |\n\n> \\[!NOTE]\n> More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request_review_comment). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n\nRuns your workflow when a pull request review comment is modified. A pull request review comment is a comment on a pull request's diff. For activity related to pull request reviews or pull request comments, use the [`pull_request_review`](#pull_request_review) or [`issue_comment`](#issue_comment) events instead. For information about the pull request review comment APIs, see [Objects](/en/graphql/reference/objects#pullrequestreviewcomment) in the GraphQL API documentation or [REST API endpoints for pull requests](/en/rest/pulls#comments).\n\nFor example, you can run a workflow when a pull request review comment has been `created` or `deleted`.\n\n```yaml\non:\n pull_request_review_comment:\n types: [created, deleted]\n```\n\n#### Workflows in forked repositories\n\nWorkflows don't run in forked repositories by default. You must enable GitHub Actions in the **Actions** tab of the forked repository.\n\nWith the exception of `GITHUB_TOKEN`, secrets are not passed to the runner when a workflow is triggered from a forked repository. The `GITHUB_TOKEN` has read-only permissions in pull requests from forked repositories. For more information, see [Use GITHUB\\_TOKEN for authentication in workflows](/en/actions/security-guides/automatic-token-authentication).\n\n#### Pull request events for forked repositories\n\nFor pull requests from a forked repository to the base repository, GitHub sends the `pull_request`, `issue_comment`, `pull_request_review_comment`, `pull_request_review`, and `pull_request_target` events to the base repository. No pull request events occur on the forked repository.\n\nWhen a first-time contributor submits a pull request to a public repository, a maintainer with write access may need to approve running workflows on the pull request. For more information, see [Approving workflow runs from forks](/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).\n\nFor pull requests from a forked repository to a private repository, workflows only run when they are enabled, see [Managing GitHub Actions settings for a repository](/en/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).\n\n> \\[!NOTE]\n> Workflows triggered by Dependabot pull requests are treated as though they are from a forked repository, and are also subject to these restrictions.\n\n## `pull_request_target`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | -------------- |\n| | | | |\n| [`pull_request`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `locked`
- `unlocked`
- `enqueued`
- `dequeued`
- `milestoned`
- `demilestoned`
- `ready_for_review`
- `review_requested`
- `review_request_removed`
- `auto_merge_enabled`
- `auto_merge_disabled` | Last commit on default branch | Default branch |\n| | | | |\n\n> \\[!NOTE]\n> More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request). By default, a workflow only runs when a `pull_request_target` event's activity type is `opened`, `synchronize`, or `reopened`. To trigger workflows by different activity types, use the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n\nRuns your workflow when activity on a pull request in the workflow's repository occurs. For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated.\n\nThis event runs in the context of the default branch of the base repository, rather than in the context of the merge commit, as the `pull_request` event does. This prevents execution of unsafe code from the head of the pull request that could alter your repository or steal any secrets you use in your workflow. This event allows your workflow to do things like label or comment on pull requests from forks. Avoid using this event if you need to build or run code from the pull request.\n\nTo ensure repository security, branches with names that match certain patterns (such as those which look similar to SHAs) may not trigger workflows with the `pull_request_target` event.\n\n> \\[!WARNING]\n> Running untrusted code on the `pull_request_target` trigger may lead to security vulnerabilities. These vulnerabilities include cache poisoning and granting unintended access to write privileges or secrets. For more information, see [Secure use reference](/en/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout) in the GitHub Enterprise Cloud documentation, and [Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) on the GitHub Security Lab website.\n\nFor example, you can run a workflow when a pull request has been `assigned`, `opened`, `synchronize`, or `reopened`.\n\n```yaml\non:\n pull_request_target:\n types: [assigned, opened, synchronize, reopened]\n```\n\n### Running your `pull_request_target` workflow based on the head or base branch of a pull request\n\nYou can use the `branches` or `branches-ignore` filter to configure your workflow to only run on pull requests that target specific branches. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore).\n\nFor example, this workflow will run when someone opens a pull request that targets a branch whose name starts with `releases/`:\n\n```yaml\non:\n pull_request_target:\n types:\n - opened\n branches:\n - 'releases/**'\n```\n\n> \\[!NOTE]\n> If you use both the `branches` filter and the `paths` filter, the workflow will only run when both filters are satisfied. For example, the following workflow will only run when a pull request that includes a change to a JavaScript (`.js`) file is opened on a branch whose name starts with `releases/`:\n>\n> ```yaml\n> on:\n> pull_request_target:\n> types:\n> - opened\n> branches:\n> - 'releases/**'\n> paths:\n> - '**.js'\n> ```\n\nTo run a job based on the pull request's head branch name (as opposed to the pull request's base branch name), use the `github.head_ref` context in a conditional. For example, this workflow will run whenever a pull request is opened, but the `run_if` job will only execute if the head of the pull request is a branch whose name starts with `releases/`:\n\n```yaml\non:\n pull_request_target:\n types:\n - opened\njobs:\n run_if:\n if: startsWith(github.head_ref, 'releases/')\n runs-on: ubuntu-latest\n steps:\n - run: echo \"The head of this PR starts with 'releases/'\"\n```\n\n### Running your `pull_request_target` workflow based on files changed in a pull request\n\nYou can use the `paths` or `paths-ignore` filter to configure your workflow to run when a pull request changes specific files. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore).\n\nFor example, this workflow will run when a pull request includes a change to a JavaScript file (`.js`):\n\n```yaml\non:\n pull_request_target:\n paths:\n - '**.js'\n```\n\n> \\[!NOTE]\n> If you use both the `branches` filter and the `paths` filter, the workflow will only run when both filters are satisfied. For example, the following workflow will only run when a pull request that includes a change to a JavaScript (`.js`) file is opened on a branch whose name starts with `releases/`:\n>\n> ```yaml\n> on:\n> pull_request_target:\n> types:\n> - opened\n> branches:\n> - 'releases/**'\n> paths:\n> - '**.js'\n> ```\n\n### Running your `pull_request_target` workflow when a pull request merges\n\nWhen a pull request merges, the pull request is automatically closed. To run a workflow when a pull request merges, use the `pull_request_target` `closed` event type along with a conditional that checks the `merged` value of the event. For example, the following workflow will run whenever a pull request closes. The `if_merged` job will only run if the pull request was also merged.\n\n```yaml\non:\n pull_request_target:\n types:\n - closed\n\njobs:\n if_merged:\n if: github.event.pull_request.merged == true\n runs-on: ubuntu-latest\n steps:\n - run: |\n echo The PR was merged\n```\n\n## `push`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |\n| [`push`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#push) | Not applicable | Tip commit pushed to the ref. When you delete a branch, the SHA in the workflow run (and its associated refs) reverts to the default branch of the repository. | Updated ref |\n\n> \\[!NOTE]\n>\n> * 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 API. For information, see [Objects](/en/graphql/reference/objects#commit) in the GraphQL API documentation or [REST API endpoints for commits](/en/rest/commits#get-a-commit).\n> * Events will not be created if more than 5,000 branches are pushed at once. Events will not be created for tags when more than three tags are pushed at once.\n\nRuns your workflow when you push a commit or tag, or when you create a repository from a template.\n\nFor example, you can run a workflow when the `push` event occurs.\n\n```yaml\non:\n push\n```\n\n> \\[!NOTE]\n> When a `push` webhook event triggers a workflow run, the Actions UI's \"pushed by\" field shows the account of the pusher and not the author or committer. However, if the changes are pushed to a repository using SSH authentication with a deploy key, then the \"pushed by\" field will be the repository admin who verified the deploy key when it was added it to a repository.\n\n### Running your workflow only when a push to specific branches occurs\n\nYou can use the `branches` or `branches-ignore` filter to configure your workflow to only run when specific branches are pushed. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore).\n\nFor example, this workflow will run when someone pushes to `main` or to a branch that starts with `releases/`.\n\n```yaml\non:\n push:\n branches:\n - 'main'\n - 'releases/**'\n```\n\n> \\[!NOTE]\n> If you use both the `branches` filter and the `paths` filter, the workflow will only run when both filters are satisfied. For example, the following workflow will only run when a push that includes a change to a JavaScript (`.js`) file is made to a branch whose name starts with `releases/`:\n>\n> ```yaml\n> on:\n> push:\n> branches:\n> - 'releases/**'\n> paths:\n> - '**.js'\n> ```\n\n### Running your workflow only when a push of specific tags occurs\n\nYou can use the `tags` or `tags-ignore` filter to configure your workflow to only run when specific tags are pushed. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore).\n\nFor example, this workflow will run when someone pushes a tag that starts with `v1.`.\n\n```yaml\non:\n push:\n tags:\n - v1.**\n```\n\n### Running your workflow only when a push affects specific files\n\nYou can use the `paths` or `paths-ignore` filter to configure your workflow to run when a push to specific files occurs. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore).\n\nFor example, this workflow will run when someone pushes a change to a JavaScript file (`.js`):\n\n```yaml\non:\n push:\n paths:\n - '**.js'\n```\n\n## `registry_package`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------------------ | ----------------------------- | ------------------------------- | -------------------------------------- |\n| [`registry_package`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#package) | - `published`
- `updated` | Commit of the published package | Branch or tag of the published package |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#registry_package). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n> * When pushing multi-architecture container images, this event occurs once per manifest, so you might observe your workflow triggering multiple times. To mitigate this, and only run your workflow job for the event that contains the actual image tag information, use a conditional:\n>\n> ```yaml\n> jobs:\n> job_name:\n> if: $true\n> ```\n\nRuns your workflow when activity related to GitHub Packages occurs in your repository. For more information, see [GitHub Packages Documentation](/en/packages).\n\nFor example, you can run a workflow when a new package version has been `published`.\n\n```yaml\non:\n registry_package:\n types: [published]\n```\n\n## `release`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | ----------------------------------------- |\n| [`release`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#release) | - `published`
- `unpublished`
- `created`
- `edited`
- `deleted`
- `prereleased`
- `released` | Last commit in the tagged release | Tag ref of release `refs/tags/` |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#release). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * Workflows are not triggered for the `created`, `edited`, or `deleted` activity types for draft releases. When you create your release through the GitHub UI, your release may automatically be saved as a draft.\n> * The `prereleased` type will not trigger for pre-releases published from draft releases, but the `published` type will trigger. If you want a workflow to run when stable *and* pre-releases publish, subscribe to `published` instead of `released` and `prereleased`.\n\nRuns your workflow when release activity in your repository occurs. For information about the release APIs, see [Objects](/en/graphql/reference/objects#release) in the GraphQL API documentation or [REST API endpoints for releases and release assets](/en/rest/releases) in the REST API documentation.\n\nFor example, you can run a workflow when a release has been `published`.\n\n```yaml\non:\n release:\n types: [published]\n```\n\n## `repository_dispatch`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| -------------------------------------------------------------------------------------------------------- | -------------- | ----------------------------- | -------------- |\n| [repository\\_dispatch](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#repository_dispatch) | Custom | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n> This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nYou can use the GitHub API to trigger a webhook event called [`repository_dispatch`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#repository_dispatch) when you want to trigger a workflow for activity that happens outside of GitHub. For more information, see [REST API endpoints for repositories](/en/rest/repos/repos#create-a-repository-dispatch-event).\n\nWhen you make a request to create a `repository_dispatch` event, you must specify an `event_type` to describe the activity type. By default, all `repository_dispatch` activity types trigger a workflow to run. You can use the `types` keyword to limit your workflow to run when a specific `event_type` value is sent in the `repository_dispatch` webhook payload.\n\n```yaml\non:\n repository_dispatch:\n types: [test_result]\n```\n\n> \\[!NOTE]\n> The `event_type` value is limited to 100 characters.\n\nAny data that you send through the `client_payload` parameter will be available in the `github.event` context in your workflow. For example, if you send this request body when you create a repository dispatch event:\n\n```json\n{\n \"event_type\": \"test_result\",\n \"client_payload\": {\n \"passed\": false,\n \"message\": \"Error: timeout\"\n }\n}\n```\n\nthen you can access the payload in a workflow like this:\n\n```yaml\non:\n repository_dispatch:\n types: [test_result]\n\njobs:\n run_if_failure:\n if: ${{ !github.event.client_payload.passed }}\n runs-on: ubuntu-latest\n steps:\n - env:\n MESSAGE: ${{ github.event.client_payload.message }}\n run: echo $MESSAGE\n```\n\n> \\[!NOTE]\n>\n> * The maximum number of top-level properties in `client_payload` is 10.\n> * The payload can contain a maximum of 65,535 characters.\n\n## `schedule`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------- | -------------- | ----------------------------- | -------------- |\n| Not applicable | Not applicable | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * The `schedule` event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n> * Scheduled workflows will only run on the default branch.\n> * In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days. For information on re-enabling a disabled workflow, see [Disabling and enabling a workflow](/en/actions/how-tos/manage-workflow-runs/disable-and-enable-workflows#enabling-a-workflow).\n\nThe `schedule` event allows you to trigger a workflow at a scheduled time.\n\n**Example:**\n\n```yaml\n on:\n schedule:\n - cron: \"15 4,5 * * *\"\n```\n\nUse [POSIX cron syntax](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) to schedule workflows to run at specific times. By default, scheduled workflows run in UTC. You can optionally specify a timezone using an [IANA timezone string](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) for timezone-aware scheduling. Scheduled workflows run on the latest commit on the default branch. The shortest interval you can run scheduled workflows is once every 5 minutes.\n\n> \\[!NOTE]\n> For schedules that set `timezone` to a time zone that observes daylight saving time (DST), during DST spring-forward transitions, scheduled workflows in skipped hours advance to the next valid time. For example, a 2:30 AM schedule advances to 3:00 AM.\n\nCron syntax has five fields separated by a space, and each field represents a unit of time.\n\n```text\n┌───────────── minute (0 - 59)\n│ ┌───────────── hour (0 - 23)\n│ │ ┌───────────── day of the month (1 - 31)\n│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)\n│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)\n│ │ │ │ │\n* * * * *\n```\n\nYou can use these operators in any of the five fields:\n\n| Operator | Description | Example |\n| -------- | -------------------- | -------------------------------------------------------------------------------------------------- |\n| \\* | Any value | `15 * * * *` runs at every minute 15 of every hour of every day. |\n| , | Value list separator | `2,10 4,5 * * *` runs at minute 2 and 10 of the 4th and 5th hour of every day. |\n| - | Range of values | `30 4-6 * * *` runs at minute 30 of the 4th, 5th, and 6th hour. |\n| / | Step values | `20/15 * * * *` runs every 15 minutes starting from minute 20 through 59 (minutes 20, 35, and 50). |\n\nThis example triggers the workflow to run at 5:30 AM in the America/New\\_York timezone every Monday through Friday:\n\n```yaml\non:\n schedule:\n - cron: '30 5 * * 1-5'\n timezone: \"America/New_York\"\n```\n\nA single workflow can be triggered by multiple `schedule` events. Access the `schedule` event that triggered the workflow through the `github.event.schedule` context. This example triggers the workflow to run at 5:30 UTC every Monday-Thursday, and 17:30 UTC on Tuesdays and Thursdays, but skips the `Not on Monday or Wednesday` step on Monday and Wednesday.\n\n```yaml\non:\n schedule:\n - cron: '30 5 * * 1,3'\n - cron: '30 5,17 * * 2,4'\n\njobs:\n test_schedule:\n runs-on: ubuntu-latest\n steps:\n - name: Not on Monday or Wednesday\n if: github.event.schedule != '30 5 * * 1,3'\n run: echo \"This step will be skipped on Monday and Wednesday\"\n - name: Every time\n run: echo \"This step will always run\"\n```\n\n> \\[!NOTE]\n> GitHub Actions does not support the non-standard syntax `@yearly`, `@monthly`, `@weekly`, `@daily`, `@hourly`, and `@reboot`.\n\nYou can use [crontab guru](https://crontab.guru/) to help generate your cron syntax and confirm what time it will run. To help you get started, there is also a list of [crontab guru examples](https://crontab.guru/examples.html).\n\n### `actor` for scheduled workflows\n\nCertain repository events change the `actor` associated with the workflow. For example, a user who changes the default branch of the repository, which changes the branch on which scheduled workflows run, becomes `actor` for those scheduled workflows.\n\nFor a deactivated scheduled workflow, if a user with `write` permissions to the repository makes a commit that changes the `cron` schedule on the workflow, the workflow will be reactivated, and that user will become the `actor` associated with any workflow runs.\n\nNotifications for scheduled workflows are sent to the user who last modified the cron syntax in the workflow file. For more information, see [Notifications for workflow runs](/en/actions/monitoring-and-troubleshooting-workflows/notifications-for-workflow-runs).\n\n> \\[!NOTE]\n> For an enterprise with Enterprise Managed Users, triggering a scheduled workflow requires that the status of the `actor` user account associated with the workflow is currently active (i.e. not suspended or deleted).\n>\n> * Scheduled workflows will not run if the last `actor` associated with the scheduled workflow has been deprovisioned by the Enterprise Managed User identity provider (IdP). However, if the last `actor` Enterprise Managed User has not been deprovisioned by the IdP, and has only been removed as a member from a given organization in the enterprise, scheduled workflows will still run with that user set as the `actor`.\n> * Similarly, for an enterprise without Enterprise Managed Users, removing a user from an organization will not prevent scheduled workflows which had that user as their `actor` from running.\n> * Thus, the *user account's* status, in both Enterprise Managed User and non-Enterprise Managed User scenarios, is what's important, *not* the user's *membership status* in the organization where the scheduled workflow is located.\n\n## `status`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------- | -------------- | ----------------------------- | -------------- |\n| [`status`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#status) | Not applicable | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n> This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nRuns your workflow when the status of a Git commit changes. For example, commits can be marked as `error`, `failure`, `pending`, or `success`. If you want to provide more details about the status change, you may want to use the [`check_run`](#check_run) event. For information about the commit status APIs, see [Objects](/en/graphql/reference/objects#status) in the GraphQL API documentation or [REST API endpoints for commits](/en/rest/commits#commit-statuses).\n\nFor example, you can run a workflow when the `status` event occurs.\n\n```yaml\non:\n status\n```\n\nIf you want to run a job in your workflow based on the new commit state, you can use the `github.event.state` context. For example, the following workflow triggers when a commit status changes, but the `if_error_or_failure` job only runs if the new commit state is `error` or `failure`.\n\n```yaml\non:\n status\njobs:\n if_error_or_failure:\n runs-on: ubuntu-latest\n if: >-\n github.event.state == 'error' ||\n github.event.state == 'failure'\n steps:\n - env:\n DESCRIPTION: ${{ github.event.description }}\n run: |\n echo The status is error or failed: $DESCRIPTION\n```\n\n## `watch`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ----------------------------------------------------------------------------- | -------------- | ----------------------------- | -------------- |\n| [`watch`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#watch) | - `started` | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. Although only the `started` activity type is supported, specifying the activity type will keep your workflow specific if more activity types are added in the future. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#watch). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nRuns your workflow when the workflow's repository is starred. For information about the pull request APIs, see [Mutations](/en/graphql/reference/mutations#addstar) in the GraphQL API documentation or [REST API endpoints for starring](/en/rest/activity/starring).\n\nFor example, you can run a workflow when someone stars a repository, which is the `started` activity type for a watch event.\n\n```yaml\non:\n watch:\n types: [started]\n```\n\n## `workflow_call`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| --------------------------- | -------------- | --------------------------- | --------------------------- |\n| Same as the caller workflow | Not applicable | Same as the caller workflow | Same as the caller workflow |\n\n`workflow_call` is used to indicate that a workflow can be called by another workflow. When a workflow is triggered with the `workflow_call` event, the event payload in the called workflow is the same event payload from the calling workflow. For more information see, [Reuse workflows](/en/actions/using-workflows/reusing-workflows).\n\nThe example below only runs the workflow when it's called from another workflow:\n\n```yaml\non: workflow_call\n```\n\n## `workflow_dispatch`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ---------------------------------------------------------------------------------------------------- | -------------- | --------------------------------------------- | ------------------------------------ |\n| [workflow\\_dispatch](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_dispatch) | Not applicable | Last commit on the `GITHUB_REF` branch or tag | Branch or tag that received dispatch |\n\n> \\[!NOTE]\n> This event will only trigger a workflow run if the workflow file exists on the default branch.\n\nTo enable a workflow to be triggered manually, you need to configure the `workflow_dispatch` event. You can manually trigger a workflow run using the GitHub API, GitHub CLI, or the GitHub UI. For more information, see [Manually running a workflow](/en/actions/managing-workflow-runs/manually-running-a-workflow).\n\n```yaml\non: workflow_dispatch\n```\n\n### Providing inputs\n\nYou can configure custom-defined input properties, default input values, and required inputs for the event directly in your workflow. When you trigger the event, you can provide the `ref` and any `inputs`. When the workflow runs, you can access the input values in the `inputs` context. For more information, see [Contexts reference](/en/actions/learn-github-actions/contexts).\n\n> \\[!NOTE]\n>\n> * The workflow will also receive the inputs in the `github.event.inputs` context. The information in the `inputs` context and `github.event.inputs` context is identical except that the `inputs` context preserves Boolean values as Booleans instead of converting them to strings. The `choice` type resolves to a string and is a single selectable option.\n> * The maximum number of top-level properties for `inputs` is 25 .\n> * The maximum payload for `inputs` is 65,535 characters.\n\nThis example defines inputs called `logLevel`, `tags`, and `environment`. You pass values for these inputs to the workflow when you run it. This workflow then prints the values to the log, using the `inputs.logLevel`, `inputs.tags`, and `inputs.environment` context properties.\n\n```yaml\non:\n workflow_dispatch:\n inputs:\n logLevel:\n description: 'Log level'\n required: true\n default: 'warning'\n type: choice\n options:\n - info\n - warning\n - debug\n tags:\n description: 'Test scenario tags'\n required: false\n type: boolean\n environment:\n description: 'Environment to run tests against'\n type: environment\n required: true\n\njobs:\n log-the-inputs:\n runs-on: ubuntu-latest\n steps:\n - run: |\n echo \"Log level: $LEVEL\"\n echo \"Tags: $TAGS\"\n echo \"Environment: $ENVIRONMENT\"\n env:\n LEVEL: ${{ inputs.logLevel }}\n TAGS: ${{ inputs.tags }}\n ENVIRONMENT: ${{ inputs.environment }}\n```\n\nIf you run this workflow from a browser you must enter values for the required inputs manually before the workflow will run.\n\n\n\nYou can also pass inputs when you run a workflow from a script, or by using GitHub CLI. For example:\n\n```shell\ngh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging\n```\n\nFor more information, see the GitHub CLI information in [Manually running a workflow](/en/actions/managing-workflow-runs/manually-running-a-workflow).\n\n## `workflow_run`\n\n| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |\n| ------------------------------------------------------------------------------------------- | --------------------------------------------------- | ----------------------------- | -------------- |\n| [`workflow_run`](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_run) | - `completed`
- `requested`
- `in_progress` | Last commit on default branch | Default branch |\n\n> \\[!NOTE]\n>\n> * More than one activity type triggers this event. The `requested` activity type does not occur when a workflow is re-run. For information about each activity type, see [Webhook events and payloads](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_run). By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the `types` keyword. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).\n> * This event will only trigger a workflow run if the workflow file exists on the default branch.\n> * You can't use `workflow_run` to chain together more than three levels of workflows. For example, if you attempt to trigger five workflows (named `B` to `F`) to run sequentially after an initial workflow `A` has run (that is: `A` → `B` → `C` → `D` → `E` → `F`), workflows `E` and `F` will not be run.\n\nThis event occurs when a workflow run is requested or completed. It allows you to execute a workflow based on execution or completion of another workflow. The workflow started by the `workflow_run` event is able to access secrets and write tokens, even if the previous workflow was not. This is useful in cases where the previous workflow is intentionally not privileged, but you need to take a privileged action in a later workflow.\n\n> \\[!WARNING]\n> Running untrusted code on the `workflow_run` trigger may lead to security vulnerabilities. These vulnerabilities include cache poisoning and granting unintended access to write privileges or secrets. For more information, see [Secure use reference](/en/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout) in the GitHub Enterprise Cloud documentation, and [Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) on the GitHub Security Lab website.\n\nIn this example, a workflow is configured to run after the separate \"Run Tests\" workflow completes.\n\n```yaml\non:\n workflow_run:\n workflows: [Run Tests]\n types:\n - completed\n```\n\nIf you specify multiple `workflows` for the `workflow_run` event, only one of the workflows needs to run. For example, a workflow with the following trigger will run whenever the \"Staging\" workflow or the \"Lab\" workflow completes.\n\n```yaml\non:\n workflow_run:\n workflows: [Staging, Lab]\n types:\n - completed\n```\n\n### Running a workflow based on the conclusion of another workflow\n\nA workflow run is triggered regardless of the conclusion of the previous workflow. If you want to run a job or step based on the result of the triggering workflow, you can use a conditional with the `github.event.workflow_run.conclusion` property. For example, this workflow will run whenever a workflow named \"Build\" completes, but the `on-success` job will only run if the \"Build\" workflow succeeded, and the `on-failure` job will only run if the \"Build\" workflow failed:\n\n```yaml\non:\n workflow_run:\n workflows: [Build]\n types: [completed]\n\njobs:\n on-success:\n runs-on: ubuntu-latest\n if: ${{ github.event.workflow_run.conclusion == 'success' }}\n steps:\n - run: echo 'The triggering workflow passed'\n on-failure:\n runs-on: ubuntu-latest\n if: ${{ github.event.workflow_run.conclusion == 'failure' }}\n steps:\n - run: echo 'The triggering workflow failed'\n```\n\n### Limiting your workflow to run based on branches\n\nYou can use the `branches` or `branches-ignore` filter to specify what branches the triggering workflow must run on in order to trigger your workflow. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_runbranchesbranches-ignore). For example, a workflow with the following trigger will only run when the workflow named `Build` runs on a branch named `canary`.\n\n```yaml\non:\n workflow_run:\n workflows: [Build]\n types: [requested]\n branches: [canary]\n```\n\n### Using data from the triggering workflow\n\nYou can access the [`workflow_run` event payload](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_run) that corresponds to the workflow that triggered your workflow. For example, if your triggering workflow generates artifacts, a workflow triggered with the `workflow_run` event can access these artifacts.\n\nThe following workflow uploads data as an artifact. (In this simplified example, the data is the pull request number.)\n\n```yaml\nname: Upload data\n\non:\n pull_request:\n\njobs:\n upload:\n runs-on: ubuntu-latest\n\n steps:\n - name: Save PR number\n env:\n PR_NUMBER: ${{ github.event.number }}\n run: |\n mkdir -p ./pr\n echo $PR_NUMBER > ./pr/pr_number\n - uses: actions/upload-artifact@v4\n with:\n name: pr_number\n path: pr/\n```\n\nWhen a run of the above workflow completes, it triggers a run of the following workflow. The following workflow uses the `github.event.workflow_run` context and the GitHub REST API to download the artifact that was uploaded by the above workflow, unzips the downloaded artifact, and comments on the pull request whose number was uploaded as an artifact.\n\n```yaml\nname: Use the data\n\non:\n workflow_run:\n workflows: [Upload data]\n types:\n - completed\n\njobs:\n download:\n runs-on: ubuntu-latest\n steps:\n - name: 'Download artifact'\n uses: actions/github-script@v8\n with:\n script: |\n let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({\n owner: context.repo.owner,\n repo: context.repo.repo,\n run_id: context.payload.workflow_run.id,\n });\n let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {\n return artifact.name == \"pr_number\"\n })[0];\n let download = await github.rest.actions.downloadArtifact({\n owner: context.repo.owner,\n repo: context.repo.repo,\n artifact_id: matchArtifact.id,\n archive_format: 'zip',\n });\n const fs = require('fs');\n const path = require('path');\n const temp = '${{ runner.temp }}/artifacts';\n if (!fs.existsSync(temp)){\n fs.mkdirSync(temp);\n }\n fs.writeFileSync(path.join(temp, 'pr_number.zip'), Buffer.from(download.data));\n\n - name: 'Unzip artifact'\n run: unzip \"${{ runner.temp }}/artifacts/pr_number.zip\" -d \"${{ runner.temp }}/artifacts\"\n\n - name: 'Comment on PR'\n uses: actions/github-script@v8\n with:\n github-token: ${{ secrets.GITHUB_TOKEN }}\n script: |\n const fs = require('fs');\n const path = require('path');\n const temp = '${{ runner.temp }}/artifacts';\n const issue_number = Number(fs.readFileSync(path.join(temp, 'pr_number')));\n await github.rest.issues.createComment({\n owner: context.repo.owner,\n repo: context.repo.repo,\n issue_number: issue_number,\n body: 'Thank you for the PR!'\n });\n```"}