触发工作流的事件

关于触发工作流的事件

工作流触发器是导致工作流运行的事件。有关如何使用工作流触发器的更多信息，请参阅“触发工作流”。

某些事件具有多种活动类型。对于这些事件，您可以指定哪些活动类型将触发工作流运行。有关每种活动类型的含义的更多信息，请参阅“Webhook 事件和有效负载”。

branch_protection_rule

当工作流存储库中的分支保护规则发生更改时运行您的工作流。有关分支保护规则的更多信息，请参阅“关于受保护分支”。有关分支保护规则 API 的信息，请参阅 GraphQL API 文档中的“对象”或“分支及其设置的 REST API 端点”。

例如，您可以创建或删除分支保护规则时运行工作流。

on:
  branch_protection_rule:
    types: [created, deleted]

check_run

当发生与检查运行相关的活动时运行您的工作流。检查运行是检查套件中一部分的单个测试。有关信息，请参阅“使用 REST API 与检查交互”。有关检查运行 API 的信息，请参阅 GraphQL API 文档中的“对象”或“检查运行的 REST API 端点”。

例如，您可以重新请求或完成检查运行时运行工作流。

on:
  check_run:
    types: [rerequested, completed]

check_suite

当发生检查套件活动时运行您的工作流。检查套件是为特定提交创建的检查运行的集合。检查套件总结了套件中检查运行的状态和结论。有关信息，请参阅“使用 REST API 与检查交互”。有关检查套件 API 的信息，请参阅 GraphQL API 文档中的“对象”或“检查套件的 REST API 端点”。

例如，您可以完成检查套件时运行工作流。

on:
  check_suite:
    types: [completed]

create

当有人在工作流的存储库中创建 Git 引用（Git 分支或标签）时运行您的工作流。有关创建 Git 引用的 API 的信息，请参阅 GraphQL API 文档中的“变异”或“Git 引用的 REST API 端点”。

例如，您可以发生create事件时运行工作流。

on:
  create

delete

当有人删除工作流存储库中的 Git 引用（Git 分支或标签）时运行您的工作流。有关删除 Git 引用的 API 的信息，请参阅 GraphQL API 文档中的“变异”或“Git 引用的 REST API 端点”。

例如，您可以发生delete事件时运行工作流。

on:
  delete

deployment

当有人在工作流的存储库中创建部署时运行您的工作流。使用提交 SHA 创建的部署可能没有 Git 引用。有关创建部署的 API 的信息，请参阅 GraphQL API 文档中的“变异”或“存储库的 REST API 端点”。

例如，您可以发生deployment事件时运行工作流。

on:
  deployment

deployment_status

当第三方提供部署状态时运行您的工作流。使用提交 SHA 创建的部署可能没有 Git 引用。有关创建部署状态的 API 的信息，请参阅 GraphQL API 文档中的“变异”或“部署的 REST API 端点”。

例如，您可以发生deployment_status事件时运行工作流。

on:
  deployment_status

discussion

当工作流的存储库中创建或修改讨论时运行您的工作流。对于与讨论评论相关的活动，请使用discussion_comment事件。有关讨论的更多信息，请参阅“关于讨论”。有关 GraphQL API 的信息，请参阅“对象”。

例如，您可以创建、编辑或解答讨论时运行工作流。

on:
  discussion:
    types: [created, edited, answered]

discussion_comment

当工作流的存储库中创建或修改讨论评论时运行您的工作流。对于与讨论本身相关的活动（而不是讨论中的评论），请使用discussion事件。有关讨论的更多信息，请参阅“关于讨论”。有关 GraphQL API 的信息，请参阅“对象”。

例如，您可以创建或删除讨论评论时运行工作流。

on:
  discussion_comment:
    types: [created, deleted]

fork

当有人派生存储库时运行您的工作流。有关 REST API 的信息，请参阅“派生的 REST API 端点”。

例如，您可以发生fork事件时运行工作流。

on:
  fork

gollum

当有人创建或更新 Wiki 页面时运行您的工作流。有关更多信息，请参阅“关于 Wiki”。

例如，您可以发生gollum事件时运行工作流。

on:
  gollum

issue_comment

当创建、编辑或删除问题或拉取请求评论时运行您的工作流。有关问题评论 API 的信息，请参阅 GraphQL API 文档中的“对象”或 REST API 文档中的“Webhook 事件和有效负载”。

例如，当创建或删除问题或拉取请求评论时，您可以运行工作流。

on:
  issue_comment:
    types: [created, deleted]

仅针对问题或仅针对拉取请求的issue_comment

issue_comment事件会针对问题和拉取请求中的评论发生。您可以使用条件中的github.event.issue.pull_request属性，根据触发对象是问题还是拉取请求采取不同的操作。

例如，此工作流将仅当issue_comment事件源自拉取请求时才运行pr_commented作业。仅当issue_comment事件源自问题时，它才会运行issue_commented作业。

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

当工作流存储库中的问题被创建或修改时运行您的工作流。对于与问题中评论相关的活动，请使用issue_comment事件。有关问题的更多信息，请参阅“关于问题”。有关问题 API 的信息，请参阅 GraphQL API 文档中的“对象”或“问题 REST API 端点”。

例如，当问题被opened（打开）、edited（编辑）或milestoned（设置里程碑）时，您可以运行工作流。

on:
  issues:
    types: [opened, edited, milestoned]

label

当工作流存储库中的标签被创建或修改时运行您的工作流。有关标签的更多信息，请参阅“管理标签”。有关标签 API 的信息，请参阅 GraphQL API 文档中的“对象”或“标签 REST API 端点”。

如果您希望在将标签添加到问题、拉取请求或讨论中或从中移除标签时运行工作流，请改用issues、pull_request、pull_request_target或discussion事件的labeled或unlabeled活动类型。

例如，当创建或删除标签时，您可以运行工作流。

on:
  label:
    types: [created, deleted]

merge_group

当将拉取请求添加到合并队列时（这会将拉取请求添加到合并组）运行您的工作流。有关更多信息，请参阅“使用合并队列合并拉取请求”。

例如，当发生checks_requested活动时，您可以运行工作流。

on:
  pull_request:
    branches: [ "main" ]
  merge_group:
    types: [checks_requested]

milestone

当工作流存储库中的里程碑被创建或修改时运行您的工作流。有关里程碑的更多信息，请参阅“关于里程碑”。有关里程碑 API 的信息，请参阅 GraphQL API 文档中的“对象”或“里程碑 REST API 端点”。

如果您希望在将问题添加到里程碑中或从中移除问题时运行工作流，请改用issues事件的milestoned或demilestoned活动类型。

例如，当里程碑被opened（打开）或deleted（删除）时，您可以运行工作流。

on:
  milestone:
    types: [opened, deleted]

page_build

如果为存储库启用了 GitHub Pages，则当有人推送到用作 GitHub Pages 发布源的分支时运行您的工作流。有关 GitHub Pages 发布源的更多信息，请参阅“配置 GitHub Pages 站点的发布源”。有关 REST API 的信息，请参阅“存储库 REST API 端点”。

例如，当发生page_build事件时，您可以运行工作流。

on:
  page_build

public

当您的工作流存储库从私有更改为公有时运行您的工作流。有关 REST API 的信息，请参阅“存储库 REST API 端点”。

例如，当发生public事件时，您可以运行工作流。

on:
  public

pull_request

当工作流所在仓库的拉取请求发生活动时，运行您的工作流。例如，如果未指定任何活动类型，则在打开或重新打开拉取请求或更新拉取请求的头部分支时，工作流将运行。对于与拉取请求审查、拉取请求审查评论或拉取请求评论相关的活动，请改用pull_request_review、pull_request_review_comment或issue_comment事件。有关拉取请求 API 的信息，请参阅 GraphQL API 文档中的“对象”或“拉取请求的 REST API 端点”。

请注意，此事件的GITHUB_SHA是拉取请求合并分支的最后一次合并提交。如果您想要获取拉取请求头部分支的最后一次提交的提交 ID，请改用github.event.pull_request.head.sha。

例如，您可以在打开或重新打开拉取请求时运行工作流。

on:
  pull_request:
    types: [opened, reopened]

您可以使用事件上下文来进一步控制工作流中的作业何时运行。例如，此工作流将在拉取请求请求审查时运行，但specific_review_requested作业仅在请求octo-team审查时运行。

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工作流

您可以使用branches或branches-ignore过滤器配置您的工作流，使其仅在针对特定分支的拉取请求上运行。有关更多信息，请参阅“GitHub Actions 的工作流语法”。

例如，当有人打开一个目标分支名称以releases/开头的拉取请求时，此工作流将运行。

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

要基于拉取请求的头部分支名称（而不是拉取请求的基础分支名称）运行作业，请在条件语句中使用github.head_ref上下文。例如，此工作流将在打开任何拉取请求时运行，但run_if作业只有在拉取请求的头部是名称以releases/开头的分支时才会执行。

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工作流

您还可以配置工作流，以便在拉取请求更改特定文件时运行。有关更多信息，请参阅“GitHub Actions 的工作流语法”。

例如，当拉取请求包含对 JavaScript 文件 (.js) 的更改时，此工作流将运行。

on:
  pull_request:
    paths:
      - '**.js'

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

在拉取请求合并时运行您的pull_request工作流

拉取请求合并后，会自动关闭拉取请求。要在拉取请求合并时运行工作流，请使用pull_request的closed事件类型以及检查事件的merged值的条件语句。例如，以下工作流将在拉取请求关闭时运行。如果拉取请求也已合并，则if_merged作业才会运行。

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 Actions。

除了GITHUB_TOKEN之外，当从派生仓库触发工作流时，不会将密钥传递给运行器。GITHUB_TOKEN在来自派生仓库的拉取请求中具有只读权限。有关更多信息，请参阅“自动令牌身份验证”。

派生仓库的拉取请求事件

对于从派生仓库到基础仓库的拉取请求，GitHub 会将pull_request、issue_comment、pull_request_review_comment、pull_request_review和pull_request_target事件发送到基础仓库。派生仓库不会发生任何拉取请求事件。

当首次贡献者向公共仓库提交拉取请求时，拥有写入权限的维护者可能需要批准在拉取请求上运行工作流。有关更多信息，请参阅“批准来自公共派生仓库的工作流运行”。

对于从派生仓库到私有仓库的拉取请求，只有在启用工作流时，工作流才会运行，请参阅“管理仓库的 GitHub Actions 设置”。

pull_request_comment（使用issue_comment）

要在创建、编辑或删除拉取请求（而不是拉取请求的差异）上的评论时运行您的工作流，请使用issue_comment事件。对于与拉取请求审查或拉取请求审查评论相关的活动，请改用pull_request_review或pull_request_review_comment事件。

pull_request_review

当提交、编辑或驳回拉取请求审查时运行您的工作流。拉取请求审查是一组拉取请求审查评论，此外还有一个正文评论和一个状态。对于与拉取请求审查评论或拉取请求评论相关的活动，请改用pull_request_review_comment或issue_comment事件。有关拉取请求审查 API 的信息，请参阅 GraphQL API 文档中的“对象”或“拉取请求的 REST API 端点”。

例如，您可以在编辑或驳回拉取请求审查时运行工作流。

on:
  pull_request_review:
    types: [edited, dismissed]

在批准拉取请求时运行工作流

要在批准拉取请求时运行您的工作流，您可以使用pull_request_review事件的submitted类型触发您的工作流，然后使用github.event.review.state属性检查审查状态。例如，此工作流将在提交拉取请求审查时运行，但approved作业只有在提交的审查是批准审查时才会运行。

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 Actions。

除了GITHUB_TOKEN之外，当从派生仓库触发工作流时，不会将密钥传递给运行器。GITHUB_TOKEN在来自派生仓库的拉取请求中具有只读权限。有关更多信息，请参阅“自动令牌身份验证”。

派生仓库的拉取请求事件

对于从派生仓库到基础仓库的拉取请求，GitHub 会将pull_request、issue_comment、pull_request_review_comment、pull_request_review和pull_request_target事件发送到基础仓库。派生仓库不会发生任何拉取请求事件。

当首次贡献者向公共仓库提交拉取请求时，拥有写入权限的维护者可能需要批准在拉取请求上运行工作流。有关更多信息，请参阅“批准来自公共派生仓库的工作流运行”。

对于从派生仓库到私有仓库的拉取请求，只有在启用工作流时，工作流才会运行，请参阅“管理仓库的 GitHub Actions 设置”。

pull_request_review_comment

修改拉取请求审查评论时运行您的工作流。拉取请求审查评论是对拉取请求差异的评论。对于与拉取请求审查或拉取请求评论相关的活动，请改用pull_request_review或issue_comment事件。有关拉取请求审查评论 API 的信息，请参阅 GraphQL API 文档中的“对象”或“拉取请求的 REST API 端点”。

例如，您可以在创建或删除拉取请求审查评论时运行工作流。

on:
  pull_request_review_comment:
    types: [created, deleted]

派生仓库中的工作流

默认情况下，工作流不会在派生仓库中运行。您必须在派生仓库的“**操作**”选项卡中启用 GitHub Actions。

除了GITHUB_TOKEN之外，当从派生仓库触发工作流时，不会将密钥传递给运行器。GITHUB_TOKEN在来自派生仓库的拉取请求中具有只读权限。有关更多信息，请参阅“自动令牌身份验证”。

派生仓库的拉取请求事件

对于从派生仓库到基础仓库的拉取请求，GitHub 会将pull_request、issue_comment、pull_request_review_comment、pull_request_review和pull_request_target事件发送到基础仓库。派生仓库不会发生任何拉取请求事件。

当首次贡献者向公共仓库提交拉取请求时，拥有写入权限的维护者可能需要批准在拉取请求上运行工作流。有关更多信息，请参阅“批准来自公共派生仓库的工作流运行”。

对于从派生仓库到私有仓库的拉取请求，只有在启用工作流时，工作流才会运行，请参阅“管理仓库的 GitHub Actions 设置”。

pull_request_target

当工作流所在仓库的拉取请求发生活动时，运行您的工作流。例如，如果未指定任何活动类型，则在打开或重新打开拉取请求或更新拉取请求的头部分支时，工作流将运行。

此事件在拉取请求的基础上下文中运行，而不是在合并提交的上下文中运行，如pull_request事件一样。这可以防止从拉取请求的头部执行不安全的代码，这些代码可能会更改您的仓库或窃取您在工作流中使用的任何密钥。此事件允许您的工作流执行诸如标记或评论来自派生仓库的拉取请求等操作。如果您需要构建或运行来自拉取请求的代码，请避免使用此事件。

为确保仓库安全，名称与特定模式匹配的分支（例如看起来类似于 SHA 的分支）可能不会触发使用pull_request_target事件的工作流程。

例如，当拉取请求被分配、打开、同步或重新打开时，您可以运行工作流程。

on:
  pull_request_target:
    types: [assigned, opened, synchronize, reopened]

基于拉取请求的头部或基础分支运行您的pull_request_target工作流程

您可以使用branches或branches-ignore过滤器配置您的工作流，使其仅在针对特定分支的拉取请求上运行。有关更多信息，请参阅“GitHub Actions 的工作流语法”。

例如，当有人打开一个目标分支名称以releases/开头的拉取请求时，此工作流将运行。

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

要基于拉取请求的头部分支名称（而不是拉取请求的基础分支名称）运行作业，请在条件语句中使用github.head_ref上下文。例如，此工作流将在打开任何拉取请求时运行，但run_if作业只有在拉取请求的头部是名称以releases/开头的分支时才会执行。

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_target工作流程

您可以使用paths或paths-ignore过滤器来配置您的工作流程，以便在拉取请求更改特定文件时运行。有关更多信息，请参阅"GitHub Actions的工作流程语法"。

例如，当拉取请求包含对 JavaScript 文件 (.js) 的更改时，此工作流将运行。

on:
  pull_request_target:
    paths:
      - '**.js'

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

拉取请求合并时运行您的pull_request_target工作流程

当拉取请求合并时，拉取请求会自动关闭。要在拉取请求合并时运行工作流程，请使用pull_request_target的closed事件类型以及检查事件的merged值的条件。例如，以下工作流程将在拉取请求关闭时运行。if_merged作业只有在拉取请求也合并的情况下才会运行。

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

当您推送提交或标签，或者当您从模板创建仓库时，运行您的工作流程。

例如，当发生push事件时，您可以运行工作流程。

on:
  push

仅当推送到特定分支时运行您的工作流程

您可以使用branches或branches-ignore过滤器来配置您的工作流程，以便仅在推送特定分支时运行。有关更多信息，请参阅"GitHub Actions的工作流程语法"。

例如，当有人推送到main或以releases/开头的分支时，此工作流程将运行。

on:
  push:
    branches:
      - 'main'
      - 'releases/**'

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

仅当推送特定标签时运行您的工作流程

您可以使用tags或tags-ignore过滤器来配置您的工作流程，以便仅在推送特定标签时运行。有关更多信息，请参阅"GitHub Actions的工作流程语法"。

例如，当有人推送以v1.开头的标签时，此工作流程将运行。

on:
  push:
    tags:
      - v1.**

仅当推送影响特定文件时运行您的工作流程

您可以使用paths或paths-ignore过滤器来配置您的工作流程，以便在向特定文件推送时运行。有关更多信息，请参阅"GitHub Actions的工作流程语法"。

例如，当有人向JavaScript文件（.js）推送更改时，此工作流程将运行。

on:
  push:
    paths:
      - '**.js'

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

registry_package

jobs:
    job_name:
        if: $true

当您的仓库中发生与GitHub Packages相关的活动时，运行您的工作流程。有关更多信息，请参阅"GitHub Packages文档"。

例如，当发布新包版本时，您可以运行工作流程。

on:
  registry_package:
    types: [published]

release

当您的仓库中发生发布活动时，运行您的工作流程。有关发布API的信息，请参阅GraphQL API文档中的"对象"或REST API文档中的"发布和发布资源的REST API端点"。

例如，当发布已发布时，您可以运行工作流程。

on:
  release:
    types: [published]

repository_dispatch

当您想为GitHub外部发生的活动触发工作流程时，您可以使用GitHub API触发名为repository_dispatch的Webhook事件。有关更多信息，请参阅"仓库的REST API端点"。

当您发出请求以创建repository_dispatch事件时，必须指定一个event_type来描述活动类型。默认情况下，所有repository_dispatch活动类型都会触发工作流程运行。您可以使用types关键字将工作流程限制为在repository_dispatchWebhook负载中发送特定event_type值时运行。

on:
  repository_dispatch:
    types: [test_result]

您通过client_payload参数发送的任何数据都将在工作流程中的github.event上下文中可用。例如，如果您在创建仓库调度事件时发送此请求正文

{
  "event_type": "test_result",
  "client_payload": {
    "passed": false,
    "message": "Error: timeout"
  }
}

那么您可以像这样在工作流程中访问负载

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

schedule

schedule事件允许您在预定的时间触发工作流程。

您可以使用POSIX cron语法安排工作流程在特定的UTC时间运行。计划的工作流程在默认分支或基础分支上的最新提交上运行。您可以运行计划的工作流程的最短间隔是每5分钟一次。

此示例每天在UTC 5:30和17:30触发工作流程。

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '30 5,17 * * *'

单个工作流程可以由多个schedule事件触发。您可以通过github.event.schedule上下文访问触发工作流程的调度事件。此示例触发工作流程在每周一至周四UTC 5:30运行，但在周一和周三跳过Not on Monday or Wednesday步骤。

on:
  schedule:
    - cron: '30 5 * * 1,3'
    - cron: '30 5 * * 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"

Cron语法由空格分隔的五个字段组成，每个字段代表一个时间单位。

┌───────────── 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)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *

您可以在五个字段中的任何一个中使用这些运算符。

您可以使用 crontab guru 来帮助生成 cron 语法并确认其运行时间。为了帮助您入门，还有一个 crontab guru 示例 列表。

计划工作流程的通知将发送给最后修改工作流程文件中 cron 语法的用户。有关更多信息，请参阅“工作流程运行通知”。

status

当 Git 提交的状态发生更改时运行您的工作流程。例如，提交可以标记为error、failure、pending 或 success。如果您想提供有关状态更改的更多详细信息，您可能需要使用 check_run 事件。有关提交状态 API 的信息，请参阅 GraphQL API 文档中的“对象”或“提交的 REST API 端点”。

例如，当发生status事件时，您可以运行工作流程。

on:
  status

如果您想根据新的提交状态在工作流程中运行作业，可以使用github.event.state上下文。例如，当提交状态更改时，以下工作流程会触发，但只有当新的提交状态为error或failure时，if_error_or_failure作业才会运行。

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

当工作流程的存储库获得星标时运行您的工作流程。有关拉取请求 API 的信息，请参阅 GraphQL API 文档中的“更改”或“加星标的 REST API 端点”。

例如，当有人为存储库加星标时（这是 watch 事件的started活动类型），您可以运行工作流程。

on:
  watch:
    types: [started]

workflow_call

workflow_call 用于指示工作流程可以由另一个工作流程调用。当使用workflow_call事件触发工作流程时，被调用工作流程中的事件有效负载与调用工作流程的事件有效负载相同。有关更多信息，请参阅“重用工作流程”。

以下示例仅在从另一个工作流程调用时运行工作流程。

on: workflow_call

workflow_dispatch

要启用手动触发工作流程，您需要配置workflow_dispatch事件。您可以使用 GitHub API、GitHub CLI 或 GitHub 浏览器界面手动触发工作流程运行。有关更多信息，请参阅“手动运行工作流程”。

on: workflow_dispatch

提供输入

您可以直接在工作流程中配置自定义定义的输入属性、默认输入值和事件的必需输入。触发事件时，您可以提供ref和任何inputs。工作流程运行时，您可以访问inputs上下文中的输入值。有关更多信息，请参阅“访问有关工作流程运行的上下文信息”。

此示例定义了名为logLevel、tags和environment的输入。运行工作流程时，您可以将这些输入的值传递给工作流程。然后，此工作流程使用inputs.logLevel、inputs.tags和inputs.environment上下文属性将值打印到日志。

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 时传递输入。例如

gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging

有关更多信息，请参阅“手动运行工作流程”中的 GitHub CLI 信息。

workflow_run

当请求或完成工作流程运行时，会发生此事件。它允许您根据另一个工作流程的执行或完成来执行工作流程。由workflow_run事件启动的工作流程能够访问密钥和写入令牌，即使以前的工作流程没有权限也是如此。这在以前的工作流程有意没有特权但您需要在以后的工作流程中采取特权操作的情况下非常有用。

在此示例中，配置工作流程在单独的“运行测试”工作流程完成后运行。

on:
  workflow_run:
    workflows: [Run Tests]
    types:
      - completed

如果您为workflow_run事件指定多个workflows，则只需要运行其中一个工作流程。例如，具有以下触发器的工作流程将在“暂存”工作流程或“实验室”工作流程完成后运行。

on:
  workflow_run:
    workflows: [Staging, Lab]
    types:
      - completed

基于另一个工作流程的结果运行工作流程

无论先前工作流程的结果如何，都会触发工作流程运行。如果您想根据触发工作流程的结果运行作业或步骤，可以使用包含github.event.workflow_run.conclusion属性的条件。例如，此工作流程将在名为“构建”的工作流程完成后运行，但只有当“构建”工作流程成功时，on-success作业才会运行；只有当“构建”工作流程失败时，on-failure作业才会运行。

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 的工作流程语法”。例如，具有以下触发器的工作流程仅在名为Build的工作流程在名为canary的分支上运行时才会运行。

on:
  workflow_run:
    workflows: [Build]
    types: [requested]
    branches: [canary]

使用来自触发工作流程的数据

您可以访问与触发您的工作流程的工作流程相对应的workflow_run事件有效负载。例如，如果您的触发工作流程生成工件，则由workflow_run事件触发的工件可以访问这些工件。

以下工作流程将数据上传为工件。（在这个简化示例中，数据是拉取请求编号。）

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@v4
        with:
          name: pr_number
          path: pr/

当上述工作流程的运行完成时，它将触发以下工作流程的运行。以下工作流程使用github.event.workflow_run上下文和 GitHub REST API 下载由上述工作流程上传的工件，解压缩下载的工件，并评论上传为工件的拉取请求。

name: Use the data

on:
  workflow_run:
    workflows: [Upload data]
    types:
      - completed

jobs:
  download:
    runs-on: ubuntu-latest
    steps:
      - name: 'Download artifact'
        uses: actions/github-script@v6
        with:
          script: |
            let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
               owner: context.repo.owner,
               repo: context.repo.repo,
               run_id: context.payload.workflow_run.id,
            });
            let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
              return artifact.name == "pr_number"
            })[0];
            let download = await github.rest.actions.downloadArtifact({
               owner: context.repo.owner,
               repo: context.repo.repo,
               artifact_id: matchArtifact.id,
               archive_format: 'zip',
            });
            let fs = require('fs');
            fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/pr_number.zip`, Buffer.from(download.data));

      - name: 'Unzip artifact'
        run: unzip pr_number.zip

      - name: 'Comment on PR'
        uses: actions/github-script@v6
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            let fs = require('fs');
            let issue_number = Number(fs.readFileSync('./pr_number'));
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: issue_number,
              body: 'Thank you for the PR!'
            });