触发工作流的事件

关于触发工作流的事件

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

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

branch_protection_rule

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

例如，你可以在分支保护规则已 created 或 deleted 时运行工作流

on:
  branch_protection_rule:
    types: [created, deleted]

check_run

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

例如，当检查运行已 rerequested 或 completed 时，你可以运行工作流。

on:
  check_run:
    types: [rerequested, completed]

check_suite

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

例如，当检查套件已 completed 时，你可以运行工作流。

on:
  check_suite:
    types: [completed]

create

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

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

on:
  create

delete

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

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

on:
  delete

deployment

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

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

on:
  deployment

deployment_status

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

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

on:
  deployment_status

讨论

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

例如，当讨论已 创建、编辑或 回答时，你可以运行工作流。

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

讨论评论

当工作流存储库中的讨论中的评论被创建或修改时，运行你的工作流。对于与讨论相关的活动（而不是讨论中的评论），请使用 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 }}

问题

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

例如，当问题 已打开、已编辑或 已添加里程碑 时，你可以运行工作流。

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

标签

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

如果要在标签添加到或从问题、请求合并或讨论中删除时运行工作流，请使用 issues、pull_request、pull_request_target 或 discussion 事件的 labeled 或 unlabeled 活动类型。

例如，您可以在标签已 created 或 deleted 时运行工作流。

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

project

当项目（经典）创建或修改时运行工作流。对于项目（经典）中的卡片或列相关的活动，请改用 project_card 或 project_column 事件。有关项目（经典）的更多信息，请参阅“关于项目（经典）”。有关项目（经典）API 的信息，请参阅 GraphQL API 文档中的“对象”或“项目（经典）的 REST API 端点”。

例如，当项目已创建或删除时，您可以运行工作流。

on:
  project:
    types: [created, deleted]

project_card

当项目（经典）上的卡片创建或修改时运行工作流。对于项目（经典）或项目（经典）中列相关的活动，请改用 project 或 project_column 事件。有关项目（经典）的更多信息，请参阅“关于项目（经典）”。有关项目卡片 API 的信息，请参阅 GraphQL API 文档中的“对象”或“项目（经典）卡片的 REST API 端点”。

例如，当项目卡片已创建或删除时，您可以运行工作流。

on:
  project_card:
    types: [created, deleted]

project_column

当项目（经典）上的列创建或修改时运行工作流。对于项目（经典）或项目（经典）中卡片相关的活动，请改用 project 或 project_card 事件。有关项目（经典）的更多信息，请参阅“关于项目（经典）”。有关项目列 API 的信息，请参阅 GraphQL API 文档中的“对象”或“项目（经典）的 REST API 端点”。

例如，当项目列已创建或删除时，您可以运行工作流。

on:
  project_column:
    types: [created, deleted]

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）

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

pull_request_review

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

例如，当 Pull Request 审核被 编辑 或 驳回 时，你可以运行工作流。

on:
  pull_request_review:
    types: [edited, dismissed]

在 Pull Request 获准时运行工作流

要在 Pull Request 获准时运行工作流，你可以使用 pull_request_review 事件的 submitted 类型触发工作流，然后使用 github.event.review.state 属性检查审核状态。例如，此工作流将在每次提交 Pull Request 审核时运行，但 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事件触发工作流。

例如，当 pull request 已被 assigned、opened、synchronize 或 reopened 时，你可以运行 workflow。

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

根据 pull request 的 head 或 base 分支运行 pull_request_target workflow

您可以使用 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 中更改的文件运行 pull_request_target workflow

你可以使用 paths 或 paths-ignore 过滤器来配置 workflow，以便在 pull request 更改特定文件时运行。有关更多信息，请参阅“GitHub Actions 的工作流语法”。

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

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

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

在 pull request 合并时运行 pull_request_target workflow

当 pull request 合并时，pull request 会自动关闭。要在一个 pull request 合并时运行 workflow，请使用 pull_request_target closed 事件类型以及一个条件来检查事件的 merged 值。例如，以下 workflow 将在每次 pull request 关闭时运行。if_merged 作业仅在 pull request 也已合并时运行。

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: ${{ github.event.registry_package.package_version.container_metadata.tag.name != '' }}

当与 GitHub Packages 相关的活动在您的存储库中发生时，运行您的工作流。有关详细信息，请参阅“GitHub Packages 文档”。

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

on:
  registry_package:
    types: [published]

release

当存储库中的版本活动发生时，运行您的工作流。有关版本 API 的信息，请参阅 GraphQL API 文档中的“对象”或 REST API 文档中的“版本和版本资产的 REST API 端点”。

例如，当版本已 published 时，您可以运行工作流。

on:
  release:
    types: [published]

repository_dispatch

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

当您发出创建 repository_dispatch 事件的请求时，您必须指定一个 event_type 来描述活动类型。默认情况下，所有 repository_dispatch 活动类型都会触发工作流运行。您可以使用 types 关键字来限制您的工作流，仅在 repository_dispatch Webhook 有效负载中发送特定 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 上下文。例如，以下工作流在提交状态更改时触发，但 if_error_or_failure 作业仅在新的提交状态为 error 或 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 端点”。

例如，当有人加星存储库时，你可以运行工作流，这是监视事件的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!'
            });