触发工作流

关于工作流触发器

工作流触发器是导致工作流运行的事件。这些事件可以是

在工作流存储库中发生的事件
在 GitHub 外部发生并在 GitHub 上触发repository_dispatch事件的事件
预定的时间
手动

例如，您可以将工作流配置为在向存储库的默认分支推送代码时、创建发布版时或打开问题时运行。

工作流触发器使用on键定义。更多信息，请参阅"GitHub Actions 的工作流语法"。

触发工作流运行会发生以下步骤

您的存储库中发生一个事件。该事件具有关联的提交 SHA 和 Git ref。
GitHub 在存储库根目录的.github/workflows目录中搜索在事件关联的提交 SHA 或 Git ref 中存在的工作流文件。
对于任何on:值与触发事件匹配的工作流，都会触发工作流运行。某些事件还需要工作流文件存在于存储库的默认分支上才能运行。

每个工作流运行都将使用事件关联的提交 SHA 或 Git ref 中存在的工作流版本。当工作流运行时，GitHub 会在运行器环境中设置GITHUB_SHA（提交 SHA）和GITHUB_REF（Git ref）环境变量。更多信息，请参阅"在变量中存储信息"。

当您使用存储库的GITHUB_TOKEN执行任务时，由GITHUB_TOKEN触发的事件（workflow_dispatch和repository_dispatch除外）不会创建新的工作流运行。这可以防止您意外创建递归工作流运行。例如，如果工作流运行使用存储库的GITHUB_TOKEN推送代码，即使存储库包含配置为在push事件发生时运行的工作流，也不会运行新的工作流。更多信息，请参阅"自动令牌身份验证"。

如果您确实希望从工作流运行中触发工作流，可以使用 GitHub 应用安装访问令牌或个人访问令牌，而不是GITHUB_TOKEN来触发需要令牌的事件。

如果您使用 GitHub App，则需要创建一个 GitHub App 并将 App ID 和私钥存储为密钥。更多信息，请参阅“在 GitHub Actions 工作流程中使用 GitHub App 进行身份验证的 API 请求”。如果您使用个人访问令牌，则需要创建一个个人访问令牌并将其存储为密钥。有关创建个人访问令牌的更多信息，请参阅“管理您的个人访问令牌”。有关存储密钥的更多信息，请参阅“在 GitHub Actions 中使用密钥”。

为了最大限度地降低 GitHub Actions 使用成本，请确保您不会创建递归或意外的工作流程运行。

例如，以下工作流程使用个人访问令牌（存储为名为 MY_TOKEN 的密钥）通过 GitHub CLI 向问题添加标签。在添加标签时运行的任何工作流程都将在执行此步骤后运行一次。

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.MY_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

相反，以下工作流程使用 GITHUB_TOKEN 向问题添加标签。它不会触发在添加标签时运行的任何工作流程。

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

使用事件触发工作流程

使用 on 键指定触发工作流程的事件。有关您可以使用的事件的更多信息，请参阅“触发工作流程的事件”。

使用单个事件

例如，具有以下 on 值的工作流程将在向工作流程存储库中的任何分支推送时运行

on: push

使用多个事件

您可以指定单个事件或多个事件。例如，具有以下 on 值的工作流程将在向存储库中的任何分支推送或有人分叉存储库时运行

on: [push, fork]

如果您指定多个事件，则只需要发生其中一个事件即可触发您的工作流程。如果您的工作流程的多个触发事件同时发生，则会触发多个工作流程运行。

使用活动类型和过滤器以及多个事件

您可以使用活动类型和过滤器来进一步控制工作流程的运行时间。更多信息，请参阅使用事件活动类型和使用过滤器。如果您为事件指定了活动类型或过滤器，并且您的工作流程会根据多个事件触发，则必须分别配置每个事件。您必须在所有事件后面附加冒号 (:)，包括没有配置的事件。

例如，具有以下 on 值的工作流程将在以下情况下运行：

创建标签
向存储库中的 main 分支推送
向启用了 GitHub Pages 的分支推送

on:
  label:
    types:
      - created
  push:
    branches:
      - main
  page_build:

使用事件活动类型

某些事件具有活动类型，可以让您更好地控制工作流程的运行时间。使用 on.<event_name>.types 定义将触发工作流程运行的事件活动类型。

例如，issue_comment 事件具有 created、edited 和 deleted 活动类型。如果您的工作流程触发 label 事件，则无论何时创建、编辑或删除标签，它都会运行。如果您为 label 事件指定 created 活动类型，则您的工作流程将在创建标签时运行，但在编辑或删除标签时不会运行。

on:
  label:
    types:
      - created

如果您指定多个活动类型，则只需要发生其中一个事件活动类型即可触发您的工作流程。如果您的工作流程的多个触发事件活动类型同时发生，则会触发多个工作流程运行。例如，以下工作流程在打开或标记问题时触发。如果打开了一个带有两个标签的问题，则会启动三个工作流程运行：一个用于打开问题的事件，两个用于两个标记问题的事件。

on:
  issues:
    types:
      - opened
      - labeled

有关每个事件及其活动类型的更多信息，请参阅“触发工作流程的事件”。

使用过滤器

某些事件具有过滤器，可以让您更好地控制工作流程的运行时间。

例如，push 事件具有 branches 过滤器，该过滤器会导致您的工作流程仅在向与 branches 过滤器匹配的分支推送时运行，而不是在任何推送时运行。

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

使用过滤器定位拉取请求事件的特定分支

使用 pull_request 和 pull_request_target 事件时，您可以将工作流程配置为仅对针对特定分支的拉取请求运行。

当您想要包含分支名称模式或同时包含和排除分支名称模式时，请使用 branches 过滤器。当您只想排除分支名称模式时，请使用 branches-ignore 过滤器。您不能在工作流程中为同一个事件同时使用 branches 和 branches-ignore 过滤器。

如果您同时定义了 branches/branches-ignore 和 paths/paths-ignore，则工作流程只有在两个过滤器都满足条件时才会运行。

branches 和 branches-ignore 关键字接受使用 *、**、+、?、! 等字符的 glob 模式来匹配多个分支名称。如果名称包含任何这些字符，并且您想要精确匹配，则需要使用 \ 转义每个特殊字符。有关 glob 模式的更多信息，请参阅“GitHub Actions 的工作流程语法”。

示例：包含分支

branches 中定义的模式将针对 Git ref 的名称进行评估。例如，以下工作流程将在针对以下内容的 pull_request 事件出现时运行：

名为 main 的分支 (refs/heads/main)
名为 mona/octocat 的分支 (refs/heads/mona/octocat)
名称以 releases/ 开头的分支，例如 releases/10 (refs/heads/releases/10)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'

如果由于分支过滤、路径过滤或提交消息而跳过了工作流程，则与该工作流程关联的检查将保持“挂起”状态。需要这些检查才能成功的拉取请求将被阻止合并。

示例：排除分支

当模式与 branches-ignore 模式匹配时，工作流程将不会运行。branches-ignore 中定义的模式将针对 Git ref 的名称进行评估。例如，以下工作流程将在出现 pull_request 事件时运行，除非拉取请求的目标是：

名为 mona/octocat 的分支 (refs/heads/mona/octocat)
名称与 releases/**-alpha 匹配的分支，例如 releases/beta/3-alpha (refs/heads/releases/beta/3-alpha)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'
      - 'releases/**-alpha'

示例：包含和排除分支

您不能使用 branches 和 branches-ignore 来过滤单个工作流程中的同一事件。如果您想要同时包含和排除单个事件的分支模式，请使用 branches 过滤器以及 ! 字符来指示应排除哪些分支。

如果您使用 ! 字符定义分支，则还必须定义至少一个不带 ! 字符的分支。如果您只想排除分支，请改用 branches-ignore。

您定义模式的顺序很重要。

匹配的否定模式（以 ! 为前缀）在正匹配之后将排除 Git ref。
否定匹配之后的匹配正模式将再次包含 Git ref。

以下工作流程将在针对 releases/10 或 releases/beta/mona 的 pull_request 事件上运行，但不会针对 releases/10-alpha 或 releases/beta/3-alpha 的拉取请求运行，因为否定模式 !releases/**-alpha 跟在正模式之后。

on:
  pull_request:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

使用过滤器定位推送事件的特定分支或标签

使用 push 事件时，您可以将工作流程配置为在特定分支或标签上运行。

当您想要包含标签名称模式或同时包含和排除标签名称模式时，请使用 tags 过滤器。当您只想排除标签名称模式时，请使用 tags-ignore 过滤器。您不能在工作流程中为同一个事件同时使用 tags 和 tags-ignore 过滤器。

如果您只定义了 tags/tags-ignore 或只定义了 branches/branches-ignore，则工作流程不会针对影响未定义 Git ref 的事件运行。如果您既没有定义 tags/tags-ignore 也没有定义 branches/branches-ignore，则工作流程将针对影响分支或标签的事件运行。如果您同时定义了 branches/branches-ignore 和 paths/paths-ignore，则工作流程只有在两个过滤器都满足条件时才会运行。

branches、branches-ignore、tags 和 tags-ignore 关键字接受使用 *、**、+、?、! 等字符的 glob 模式来匹配多个分支或标签名称。如果名称包含任何这些字符，并且您想要精确匹配，则需要转义每个特殊字符，方法是在其前面添加 \。有关 glob 模式的更多信息，请参阅“GitHub Actions 的工作流程语法”。

示例：包含分支和标签

branches 和 tags 中定义的模式将针对 Git ref 的名称进行评估。例如，以下工作流程将在向以下内容推送 push 事件时运行：

名为 main 的分支 (refs/heads/main)
名为 mona/octocat 的分支 (refs/heads/mona/octocat)
名称以 releases/ 开头的分支，例如 releases/10 (refs/heads/releases/10)
名为 v2 的标签 (refs/tags/v2)
名称以 v1. 开头的标签，例如 v1.9.1 (refs/tags/v1.9.1)

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'
    # Sequence of patterns matched against refs/tags
    tags:
      - v2
      - v1.*

示例：排除分支和标签

当模式与 branches-ignore 或 tags-ignore 模式匹配时，工作流程将不会运行。branches 和 tags 中定义的模式将针对 Git ref 的名称进行评估。例如，以下工作流程将在出现 push 事件时运行，除非 push 事件的目标是：

名为 mona/octocat 的分支 (refs/heads/mona/octocat)
名称与 releases/**-alpha 匹配的分支，例如 releases/beta/3-alpha (refs/heads/releases/beta/3-alpha)
名为 v2 的标签 (refs/tags/v2)
名称以 v1. 开头的标签，例如 v1.9 (refs/tags/v1.9)

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'
      - 'releases/**-alpha'
    # Sequence of patterns matched against refs/tags
    tags-ignore:
      - v2
      - v1.*

示例：包含和排除分支和标签

您不能使用 branches 和 branches-ignore 来过滤单个工作流程中的同一事件。同样，您不能使用 tags 和 tags-ignore 来过滤单个工作流程中的同一事件。如果您想要同时包含和排除单个事件的分支或标签模式，请使用 branches 或 tags 过滤器以及 ! 字符来指示应排除哪些分支或标签。

如果您使用 ! 字符定义分支，则还必须定义至少一个不带 ! 字符的分支。如果您只想排除分支，请改用 branches-ignore。同样，如果您使用 ! 字符定义标签，则还必须定义至少一个不带 ! 字符的标签。如果您只想排除标签，请改用 tags-ignore。

您定义模式的顺序很重要。

匹配的否定模式（以 ! 为前缀）在正匹配之后将排除 Git ref。
否定匹配之后的匹配正模式将再次包含 Git ref。

以下工作流程将在推送至releases/10或releases/beta/mona时运行，但不会在推送至releases/10-alpha或releases/beta/3-alpha时运行，因为否定模式!releases/**-alpha位于肯定模式之后。

on:
  push:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

使用过滤器定位拉取请求或推送事件的特定路径

使用push和pull_request事件时，您可以配置工作流程，使其根据更改的文件路径运行。对于标签的推送，不会评估路径过滤器。

当您想要包含文件路径模式或同时包含和排除文件路径模式时，请使用paths过滤器。当您只想排除文件路径模式时，请使用paths-ignore过滤器。您不能在工作流程中为同一个事件同时使用paths和paths-ignore过滤器。如果您想同时包含和排除单个事件的路径模式，请使用以!字符为前缀的paths过滤器来指示应排除哪些路径。

注意

定义paths模式的顺序很重要

肯定匹配后出现的匹配否定模式（以!为前缀）将排除该路径。
否定匹配后出现的匹配肯定模式将再次包含该路径。

如果您同时定义branches/branches-ignore和paths/paths-ignore，则只有在两个过滤器都满足条件时，工作流程才会运行。

paths和paths-ignore关键字接受使用*和**通配符匹配多个路径名称的 glob 模式。更多信息，请参阅“GitHub Actions 的工作流程语法”。

示例：包含路径

如果至少有一条路径与paths过滤器中的模式匹配，则工作流程将运行。例如，以下工作流程将在您推送 JavaScript 文件（.js）时运行。

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

如果由于路径过滤、分支过滤或提交消息而跳过了工作流程，则与该工作流程关联的检查将保持“挂起”状态。需要这些检查成功的拉取请求将无法合并。

示例：排除路径

当所有路径名称都与paths-ignore中的模式匹配时，工作流程将不会运行。如果任何路径名称与paths-ignore中的模式不匹配，即使某些路径名称与这些模式匹配，工作流程也会运行。

具有以下路径过滤器的工作流程将仅在push事件包含存储库根目录下docs目录之外至少一个文件时运行。

on:
  push:
    paths-ignore:
      - 'docs/**'

示例：包含和排除路径

您不能使用paths和paths-ignore来过滤单个工作流程中的同一事件。如果您想同时包含和排除单个事件的路径模式，请使用以!字符为前缀的paths过滤器来指示应排除哪些路径。

如果您使用!字符定义路径，则还必须定义至少一条不带!字符的路径。如果您只想排除路径，请改用paths-ignore。

定义paths模式的顺序很重要

肯定匹配后出现的匹配否定模式（以!为前缀）将排除该路径。
否定匹配后出现的匹配肯定模式将再次包含该路径。

此示例在push事件包含sub-project目录或其子目录中的文件时运行，除非该文件位于sub-project/docs目录中。例如，更改sub-project/index.js或sub-project/src/index.js的推送将触发工作流程运行，但仅更改sub-project/docs/readme.md的推送不会触发。

on:
  push:
    paths:
      - 'sub-project/**'
      - '!sub-project/docs/**'

Git diff 比较

注意

如果您推送超过 1000 次提交，或者由于超时而 GitHub 未生成 diff，则工作流程将始终运行。

过滤器通过评估更改的文件并将它们与paths-ignore或paths列表进行比较来确定是否应运行工作流程。如果没有更改任何文件，则工作流程将不会运行。

GitHub 使用两点 diff（用于推送）和三点 diff（用于拉取请求）来生成更改文件的列表

拉取请求：三点 diff 是主题分支的最新版本与主题分支上次与基分支同步的提交之间的比较。
对现有分支的推送：两点 diff 直接比较头和基 SHA。
对新分支的推送：针对推送的最深提交的祖先的父级的两点 diff。

diff 限制为 300 个文件。如果更改的文件未在过滤器返回的前 300 个文件中匹配，则工作流程将不会运行。您可能需要创建更具体的过滤器，以便工作流程会自动运行。

更多信息，请参阅“关于在拉取请求中比较分支”。

使用过滤器定位工作流程运行事件的特定分支

使用workflow_run事件时，您可以指定触发工作流程必须运行的分支，以便触发您的工作流程。

branches和branches-ignore过滤器接受使用*、**、+、?、!等字符匹配多个分支名称的 glob 模式。如果名称包含任何这些字符，并且您需要精确匹配，则需要使用\转义每个特殊字符。有关 glob 模式的更多信息，请参阅“GitHub Actions 的工作流程语法”。

例如，具有以下触发器的运行将仅在名为Build的工作流程在名称以releases/开头的分支上运行时运行

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'

具有以下触发器的运行将仅在名为Build的工作流程在未命名为canary的分支上运行时运行

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches-ignore:
      - "canary"

您不能在工作流程中为同一个事件同时使用branches和branches-ignore过滤器。如果您想同时包含和排除单个事件的分支模式，请使用branches过滤器以及!字符来指示应排除哪些分支。

您定义模式的顺序很重要。

肯定匹配后出现的匹配否定模式（以!为前缀）将排除该分支。
否定匹配后出现的匹配肯定模式将再次包含该分支。

例如，具有以下触发器的运行将在名为Build的工作流程在名为releases/10或releases/beta/mona的分支上运行时运行，但不会在releases/10-alpha、releases/beta/3-alpha或main上运行。

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

定义手动触发工作流程的输入

使用workflow_dispatch事件时，您可以选择指定传递给工作流程的输入。

此触发器仅在工作流程文件位于默认分支上时接收事件。触发的运行在inputs上下文中接收输入。更多信息，请参阅“上下文”。

注意

工作流程还将在github.event.inputs上下文中接收输入。inputs上下文和github.event.inputs上下文中的信息是相同的，只是inputs上下文将布尔值保留为布尔值，而不是将其转换为字符串。choice类型解析为字符串，并且是一个可选择的选项。
inputs的顶级属性的最大数量为 10。
inputs的最大有效负载为 65,535 个字符。

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
          - info
          - warning
          - debug
      print_tags:
        description: 'True to print to STDOUT'
        required: true
        type: boolean
      tags:
        description: 'Test scenario tags'
        required: true
        type: string
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true

jobs:
  print-tag:
    runs-on: ubuntu-latest
    if:  ${{ inputs.print_tags }} 
    steps:
      - name: Print the input tag to STDOUT
        run: echo  The tags are ${{ inputs.tags }}

为可重用工作流程定义输入、输出和机密

您可以定义可重用工作流程应从调用工作流程接收的输入和机密。您还可以指定可重用工作流程将提供给调用工作流程的输出。更多信息，请参阅“重用工作流程”。

使用事件信息

有关触发工作流程运行的事件的信息可在github.event上下文中获得。github.event上下文中的属性取决于触发工作流程的事件类型。例如，在标记问题时触发的运行将包含有关问题和标签的信息。

查看事件的所有属性

参考 Webhook 事件文档以了解常用属性和示例有效负载。更多信息，请参阅“Webhook 事件和有效负载”。

您还可以打印整个github.event上下文以查看触发工作流程的事件可用的属性

jobs:
  print_context:
    runs-on: ubuntu-latest
    steps:
      - env:
          EVENT_CONTEXT: ${{ toJSON(github.event) }}
        run: |
          echo $EVENT_CONTEXT

访问和使用事件属性

您可以在工作流程中使用github.event上下文。例如，以下工作流程在打开更改package*.json、.github/CODEOWNERS或.github/workflows/**的拉取请求时运行。如果拉取请求作者（github.event.pull_request.user.login）不是octobot或dependabot[bot]，则工作流程将使用 GitHub CLI 为拉取请求（github.event.pull_request.number）添加标签和注释。

on:
  pull_request:
    types:
      - opened
    paths:
      - '.github/workflows/**'
      - '.github/CODEOWNERS'
      - 'package*.json'

jobs:
  triage:
    if: >-
      github.event.pull_request.user.login != 'octobot' &&
      github.event.pull_request.user.login != 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - name: "Comment about changes we can't accept"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR: ${{ github.event.pull_request.html_url }}
        run: |
          gh pr edit $PR --add-label 'invalid'
          gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'

有关上下文的更多信息，请参阅“访问有关工作流程运行的上下文信息”。有关事件有效负载的更多信息，请参阅“Webhook 事件和有效负载”。

进一步控制工作流程的运行方式

如果您需要比事件、事件活动类型或事件过滤器提供的更细粒度的控制，您可以使用条件和环境来控制工作流程中各个作业或步骤是否运行。

使用条件

您可以使用条件来进一步控制工作流程中作业或步骤是否运行。

使用事件有效负载中的值的示例

例如，如果您希望工作流程在向问题添加特定标签时运行，您可以触发issues labeled事件活动类型，并使用条件检查触发工作流程的标签。以下工作流程将在向工作流程存储库中的问题添加任何标签时运行，但run_if_label_matches作业仅在标签名为bug时才执行。

on:
  issues:
    types:
      - labeled

jobs:
  run_if_label_matches:
    if: github.event.label.name == 'bug'
    runs-on: ubuntu-latest
    steps:
      - run: echo 'The label was bug'

使用事件类型的示例

例如，如果您希望根据触发工作流程的事件运行不同的作业或步骤，您可以使用条件检查事件上下文中是否存在特定事件类型。以下工作流程将在关闭问题或拉取请求时运行。如果工作流程由于关闭问题而运行，则github.event上下文将包含issue的值，但不包含pull_request的值。因此，if_issue步骤将运行，但if_pr步骤将不会运行。相反，如果工作流程由于关闭拉取请求而运行，则if_pr步骤将运行，但if_issue步骤将不会运行。

on:
  issues:
    types:
      - closed
  pull_request:
    types:
      - closed

jobs:
  state_event_type:
    runs-on: ubuntu-latest
    steps:
    - name: if_issue
      if: github.event.issue
      run: |
        echo An issue was closed
    - name: if_pr
      if: github.event.pull_request
      run: |
        echo A pull request was closed

有关事件上下文中的可用信息，请参阅“使用事件信息”。有关如何使用条件的更多信息，请参阅“在工作流和操作中评估表达式”。

使用环境手动触发工作流作业

如果要手动触发工作流中的特定作业，可以使用需要特定团队或用户批准的环境。首先，配置一个需要审核员的环境。更多信息，请参阅“管理部署环境”。然后，使用environment:键在工作流中的作业中引用环境名称。任何引用该环境的作业只有在至少一位审核员批准该作业后才会运行。

例如，以下工作流将在每次向主分支推送代码时运行。build作业将始终运行。publish作业只有在build作业成功完成（由于needs: [build]）并且名为production的环境的所有规则（包括必需的审核员）都通过后才会运行（由于environment: production）。

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: build
        echo 'building'

  publish:
    needs: [build]
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: publish
        echo 'publishing'

在所有当前GitHub计划中，公共存储库都提供环境、环境密钥和部署保护规则。它们在旧计划（例如青铜、白银或黄金）中不可用。要访问私有或内部存储库中的环境、环境密钥和部署分支，您必须使用GitHub Pro、GitHub Team或GitHub Enterprise。如果您使用的是GitHub免费版、GitHub Pro或GitHub Team计划，其他部署保护规则（例如等待计时器或必需的审核员）仅适用于公共存储库。

可用事件

有关可用事件的完整列表，请参阅“触发工作流的事件”。

本文内容

关于工作流触发器

从工作流触发工作流

使用事件触发工作流程

使用单个事件

使用多个事件

使用活动类型和过滤器以及多个事件

使用事件活动类型

使用过滤器

使用过滤器定位拉取请求事件的特定分支

示例：包含分支

示例：排除分支

示例：包含和排除分支

使用过滤器定位推送事件的特定分支或标签

示例：包含分支和标签

示例：排除分支和标签

示例：包含和排除分支和标签

使用过滤器定位拉取请求或推送事件的特定路径

示例：包含路径

示例：排除路径

示例：包含和排除路径

Git diff 比较

使用过滤器定位工作流程运行事件的特定分支

定义手动触发工作流程的输入

为可重用工作流程定义输入、输出和机密

使用事件信息

查看事件的所有属性

访问和使用事件属性

进一步控制工作流程的运行方式

使用条件

使用事件有效负载中的值的示例

使用事件类型的示例

使用环境手动触发工作流作业

可用事件