{"meta":{"title":"触发工作流程","intro":"如何自动触发 GitHub Actions 工作流程","product":"GitHub Actions","breadcrumbs":[{"href":"/zh/actions","title":"GitHub Actions"},{"href":"/zh/actions/how-tos","title":"操作方法"},{"href":"/zh/actions/how-tos/write-workflows","title":"编写工作流"},{"href":"/zh/actions/how-tos/write-workflows/choose-when-workflows-run","title":"选择工作流何时运行"},{"href":"/zh/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow","title":"触发工作流"}],"documentType":"article"},"body":"# 触发工作流程\n\n如何自动触发 GitHub Actions 工作流程\n\n## 先决条件\n\n若要了解有关工作流和触发工作流的详细信息，请参阅 [工作流](/zh/actions/concepts/workflows-and-actions/workflows)。\n\n## 从一个工作流程中触发另一个工作流程\n\n使用存储库 `GITHUB_TOKEN` 执行任务时，由 `GITHUB_TOKEN` 该存储库触发的事件不会创建新的工作流运行，但以下例外：\n\n* `workflow_dispatch` 和 `repository_dispatch` 事件始终触发工作流运行。\n\n对于所有其他事件，此行为可防止意外创建递归的工作流运行实例。 例如，如果工作流运行使用存储库的 `GITHUB_TOKEN` 推送代码，则即使存储库包含配置为在 `push` 事件发生时运行的工作流，新工作流也不会运行。 有关详细信息，请参阅“[在工作流中使用 GITHUB\\_TOKEN 进行身份验证](/zh/actions/security-guides/automatic-token-authentication)”。\n\n如果确实要从工作流运行中触发工作流，可以使用 GitHub App 安装访问令牌或 personal access token（而不是 `GITHUB_TOKEN`）来触发需要令牌的事件。\n\n如果使用 GitHub App，则需要创建 GitHub App 并将应用 ID 和私钥存储为机密。 有关详细信息，请参阅“[在GitHub Actions工作流中使用GitHub应用发出经过身份验证的 API 请求](/zh/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow)”。 如果使用 personal access token，则需要创建 personal access token 并将其存储为机密。 有关创建 personal access token 的详细信息，请参阅 [管理个人访问令牌](/zh/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)。 有关存储机密的详细信息，请参阅“[在 GitHub Actions 中使用机密](/zh/actions/security-guides/using-secrets-in-github-actions)”。\n\n为了最大限度地降低 GitHub Actions 使用成本，请确保不要创建递归或意料之外的工作流程运行。\n\n例如，以下工作流使用 personal access token（存储为称为 `MY_TOKEN` 的机密）通过 GitHub CLI 向问题添加标签。 添加标签时运行的任何工作流程都将在执行此步骤后运行。\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.MY_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\n相反，以下工作流使用 `GITHUB_TOKEN` 向问题添加标签。 它不会触发在添加标签时运行的任何工作流程。\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\n## 使用事件触发工作流程\n\n使用 `on` 键指定触发工作流的事件。 有关可以使用的事件的详细信息，请参阅“[触发工作流的事件](/zh/actions/using-workflows/events-that-trigger-workflows)”。\n\n### 使用单个事件\n\n例如，当推送到工作流存储库中的任何分支时，将运行具有以下 `on` 值的工作流：\n\n```yaml\non: push\n```\n\n### 使用多个事件\n\n可以指定单个事件或多个事件。 例如，当推送到存储库中的任何分支或有人创建存储库的分支时，将运行具有以下 `on` 值的工作流：\n\n```yaml\non: [push, fork]\n```\n\n如果指定多个事件，仅需发生其中一个事件就可触发工作流。 如果触发工作流的多个事件同时发生，将触发多个工作流运行。\n\n### 将活动类型和筛选器用于多个事件\n\n您可以使用活动类型和筛选器进一步控制工作流程的运行时间。 有关详细信息，请参阅[使用事件活动类型](#using-event-activity-types)和[使用筛选器](#using-filters)。 如果为事件指定活动类型或筛选器，并且针对多个事件指定工作流触发器，则必须单独配置每个事件。 必须为所有事件附加冒号 (`:`)，包括没有配置的事件。\n\n例如，具有以下 `on` 值的工作流将在以下情况下运行：\n\n* 创建标签\n* 推送到存储库中的 `main` 分支\n* 推送到启用了 GitHub Pages 的分支\n\n```yaml\non:\n  label:\n    types:\n      - created\n  push:\n    branches:\n      - main\n  page_build:\n```\n\n## 使用事件活动类型\n\n某些事件具有活动类型，可让你更好地控制工作流的运行时间。 使用 `on.<event_name>.types` 定义将触发工作流运行的事件活动类型。\n\n例如，`issue_comment` 事件具有 `created`、`edited` 和 `deleted` 活动类型。 如果工作流在 `label` 事件上触发，则每当创建、编辑或删除标签时，它都会运行。 如果为 `label` 事件指定 `created` 活动类型，则工作流将在创建标签时运行，但不会在编辑或删除标签时运行。\n\n```yaml\non:\n  label:\n    types:\n      - created\n```\n\n如果指定多个活动类型，则只需要发生其中一种事件活动类型就可触发工作流。 如果触发工作流的多个事件活动类型同时发生，则将触发多个工作流运行。 例如，创建或标记问题时，会触发以下工作流。 如果创建了一个带两个标签的问题，则将启动三个工作流运行：一个用于创建问题的事件，另外两个用于两个标记问题的事件。\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n      - labeled\n```\n\n有关每个事件及其活动类型的详细信息，请参阅“[触发工作流的事件](/zh/actions/using-workflows/events-that-trigger-workflows)”。\n\n## 使用筛选器\n\n某些事件具有筛选器，可让你更好地控制工作流的运行时间。\n\n例如，`push` 事件具有 `branches` 筛选器，该筛选器仅在发生目标为与 `branches` 筛选器匹配的分支的推送时（而不是在发生任何推送时）运行工作流。\n\n```yaml\non:\n  push:\n    branches:\n      - main\n      - 'releases/**'\n```\n\n### 使用筛选器定位拉取请求事件的特定分支\n\n使用 `pull_request` 和 `pull_request_target` 事件时，可以将工作流配置为仅针对面向特定分支的拉取请求运行。\n\n如果要包含分支名称模式或同时包含和排除分支名称模式，请使用 `branches` 筛选器。 只希望排除分支名称时，请使用 `branches-ignore` 筛选器。 不能对工作流中的同一事件同时使用 `branches` 和 `branches-ignore` 筛选器。\n\n如果你同时定义 `branches`/`branches-ignore` 和 [`paths`/`paths-ignore`](/zh/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)，则工作流将只在这两个筛选器都满足条件时运行。\n\n`branches` 和 `branches-ignore` 关键词接受使用 `*`、`**`、`+`、`?` 和 `!` 等字符匹配多个路径名称的 glob 模式。 如果名称包含其中任一字符，而你想要逐字匹配，则需要使用 `\\` 转义每个特殊字符。 有关 glob 模式的详细信息，请参阅 [GitHub Actions 的工作流语法](/zh/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)。\n\n#### 示例：包括分支\n\n在 `branches` 中定义的模式根据 Git 引用的名称进行评估。 例如，每当有针对面向以下内容拉取请求的 `pull_request` 事件时，以下工作流都会运行：\n\n* 名为 `main` 的分支 (`refs/heads/main`)\n* 名为 `mona/octocat` 的分支 (`refs/heads/mona/octocat`)\n* 名称以 `releases/` 开头的分支，如 `releases/10` (`refs/heads/releases/10`)\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n```\n\n如果因分支筛选、[路径筛选](/zh/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)或[提交消息](/zh/actions/managing-workflow-runs/skipping-workflow-runs)而跳过某工作流，则与该工作流关联的检查将保持为“挂起”状态。 要求这些检查成功的拉取请求将被阻止合并。\n\n#### 示例：排除分支\n\n当模式与 `branches-ignore` 模式匹配时，工作流将不会运行。 在 `branches-ignore` 中定义的模式根据 Git 引用的名称进行评估。 例如，除非拉取请求面向以下内容，否则每当有 `pull_request` 事件时，以下工作流都会运行：\n\n* 名为 `mona/octocat` 的分支 (`refs/heads/mona/octocat`)\n* 名称匹配 `releases/**-alpha` 的分支，如 `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n```\n\n#### 示例：包括和排除分支\n\n不能在单个工作流中使用 `branches` 和 `branches-ignore` 筛选同一事件。 如果要同时包括和排除单个事件的分支模式，请使用 `branches` 筛选器以及 `!` 字符来指示应排除哪些分支或标记。\n\n如果使用字符 `!` 定义分支，则还必须至少定义一个没有 `!` 字符的分支。 如果只想排除分支，请改用 `branches-ignore`。\n\n您定义模式事项的顺序。\n\n* 肯定匹配后的匹配否定模式（前缀为 `!`）将排除 Git 引用。\n* 否定匹配后的匹配肯定模式将再次包含 Git 引用。\n\n以下工作流将在针对面向 `pull_request` 或 `releases/10` 的拉取请求的 `releases/beta/mona` 事件上运行，但不针对面向 `releases/10-alpha` 或 `releases/beta/3-alpha` 的拉取请求，由于负模式，`!releases/**-alpha` 将遵循正模式。 <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n### 使用筛选器定位推送事件的特定分支或标记\n\n使用 `push` 事件时，可以将工作流配置为在特定分支或标记上运行。\n\n如果要包含分支名称模式或要同时包含和排除分支名称模式，请使用 `branches` 筛选器。 只希望排除分支名称时，请使用 `branches-ignore` 筛选器。 不能对工作流中的同一事件同时使用 `branches` 和 `branches-ignore` 筛选器。\n\n如果要包含标记名称模式或要同时包含和排除标记名称模式，请使用 `tags` 筛选器。 只需要排除标记名称模式时，请使用 `tags-ignore` 筛选器。 不能对工作流中的同一事件同时使用 `tags` 和 `tags-ignore` 筛选器。\n\n如果仅定义了 `tags`/`tags-ignore` 或者仅定义了 `branches`/`branches-ignore`，那么对于影响未定义的 Git 引用的事件，工作流将不会运行。如果既未定义 `tags`/`tags-ignore` 也未定义 `branches`/`branches-ignore`，则工作流将针对影响分支或标记的事件运行。 如果你同时定义 `branches`/`branches-ignore` 和 [`paths`/`paths-ignore`](/zh/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)，则工作流将只在这两个筛选器都满足条件时运行。\n\n`branches`、`branches-ignore`、`tags` 和 `tags-ignore` 关键词接受使用 `*`、`**`、`+`、`?` 和 `!` 等字符匹配多个分支或标记名称的 glob 模式。 如果名称包含其中任一字符，而你想要逐字匹配，则需要使用 `\\` 转义每个特殊字符。 有关 glob 模式的详细信息，请参阅 [GitHub Actions 的工作流语法](/zh/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)。\n\n#### 示例：包括分支和标记\n\n在 `branches` 和 `tags` 中定义的模式根据 Git ref 的名称进行评估。 例如，当以下项出现 `push` 事件时，将运行以下工作流：\n\n* 名为 `main` 的分支 (`refs/heads/main`)\n* 名为 `mona/octocat` 的分支 (`refs/heads/mona/octocat`)\n* 名称以 `releases/` 开头的分支，如 `releases/10` (`refs/heads/releases/10`)\n* 名为 `v2` 的标记 (`refs/tags/v2`)\n* 名称以 `v1.` 开头的标记，如 `v1.9.1` (`refs/tags/v1.9.1`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n    # Sequence of patterns matched against refs/tags\n    tags:\n      - v2\n      - v1.*\n```\n\n#### 示例：排除分支和标记\n\n当某个模式与 `branches-ignore` 或 `tags-ignore` 模式匹配时，工作流将不会运行。 在 `branches` 和 `tags` 中定义的模式根据 Git ref 的名称进行评估。 例如，只要出现 `push` 事件，就会运行以下工作流，除非以下项出现 `push` 事件：\n\n* 名为 `mona/octocat` 的分支 (`refs/heads/mona/octocat`)\n* 名称与 `releases/**-alpha` 匹配的分支，如 `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n* 名为 `v2` 的标记 (`refs/tags/v2`)\n* 名称以 `v1.` 开头的标记，如 `v1.9` (`refs/tags/v1.9`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n    # Sequence of patterns matched against refs/tags\n    tags-ignore:\n      - v2\n      - v1.*\n```\n\n#### 示例：包括和排除分支和标签\n\n不能在一个工作流中使用 `branches` 和 `branches-ignore` 筛选同一事件。 同样，不能在一个工作流中使用 `tags` 和 `tags-ignore` 筛选同一事件。 如果要同时包括和排除一个事件的分支或标记模式，请使用 `branches` 或 `tags` 筛选器以及 `!` 字符来指示应排除哪些分支或标记。\n\n如果使用字符 `!` 定义分支，则还必须至少定义一个没有 `!` 字符的分支。 如果只想排除分支，请改用 `branches-ignore`。 同样，如果使用字符 `!` 定义标记，则还必须至少定义一个没有 `!` 字符的标记。 如果只想排除标记，请改用 `tags-ignore`。\n\n您定义模式事项的顺序。\n\n* 肯定匹配后的匹配否定模式（前缀为 `!`）将排除 Git 引用。\n* 否定匹配后的匹配肯定模式将再次包含 Git 引用。\n\n以下工作流将在推送到 `releases/10` 或 `releases/beta/mona` 时运行，但不在推送到 `releases/10-alpha` 或 `releases/beta/3-alpha` 时运行，因为否定模式 `!releases/**-alpha` 遵循肯定模式。 <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  push:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n### 使用筛选器定位拉取请求或推送事件的特定路径\n\n使用 `push` 和 `pull_request` 事件时，可以配置工作流以根据更改的文件路径运行。 路径筛选器不会针对标记的推送进行评估。\n\n如果想要包括文件路径模式或想要同时包括和排除文件路径模式，请使用 `paths` 筛选器。 如果只想排除文件路径模式，请使用 `paths-ignore` 筛选器。 不能对工作流中的同一事件同时使用 `paths` 和 `paths-ignore` 筛选器。 如果要同时包括和排除单个事件的路径模式，请使用前缀为 `!` 字符的 `paths` 筛选器来指示应排除哪些路径。\n\n> \\[!NOTE]\n> 您定义 `paths` 模式事项的顺序：\n>\n> * 肯定匹配后的匹配否定模式（前缀为 `!`）将排除路径。\n> * 否定匹配后的匹配肯定模式将再次包含路径。\n\n如果你同时定义 `branches`/`branches-ignore` 筛选器和 `paths`/`paths-ignore` 筛选器，则工作流将只在这两个筛选器都满足条件时运行。\n\n`paths` 和 `paths-ignore` 关键字接受使用 `*` 和 `**` 通配符匹配多个路径名的 glob 模式。 有关详细信息，请参阅“[GitHub Actions 的工作流语法](/zh/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)”。\n\n#### 示例：包括路径\n\n如果至少一个路径与 `paths` 筛选器中的模式匹配，则工作流将运行。 例如，只要推送 JavaScript 文件 (`.js`)，就会运行以下工作流。\n\n```yaml\non:\n  push:\n    paths:\n      - '**.js'\n```\n\n如果因路径筛选、[分支筛选](/zh/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore)或[提交消息](/zh/actions/managing-workflow-runs/skipping-workflow-runs)而跳过某工作流，则与该工作流关联的检查将保持为“挂起”状态。 要求这些检查成功的拉取请求将被阻止合并。\n\n#### 示例：排除路径\n\n当所有路径名称匹配 `paths-ignore` 中的模式时，工作流不会运行。 如果任何路径名与 `paths-ignore` 中的模式不匹配，即使某些路径名与模式匹配，工作流也会运行。\n\n具有以下路径筛选器的工作流将仅在 `push` 事件上运行，这些事件包括至少一个位于存储库根目录的 `docs` 目录外的文件。\n\n```yaml\non:\n  push:\n    paths-ignore:\n      - 'docs/**'\n```\n\n#### 示例：包括和排除路径\n\n不能在单个工作流中使用 `paths` 和 `paths-ignore` 筛选同一事件。 如果要同时包括和排除单个事件的路径模式，请使用前缀为 `!` 字符的 `paths` 筛选器来指示应排除哪些路径。\n\n如果使用 `!` 字符定义路径，则还必须定义至少一个不带 `!` 字符的路径。 如果只想排除路径，请改用 `paths-ignore`。\n\n您定义 `paths` 模式事项的顺序：\n\n* 肯定匹配后的匹配否定模式（前缀为 `!`）将排除路径。\n* 否定匹配后的匹配肯定模式将再次包含路径。\n\n只要 `push` 事件包括 `sub-project` 目录或其子目录中的文件，此示例就会运行，除非该文件在 `sub-project/docs` 目录中。 例如，更改了 `sub-project/index.js` 或 `sub-project/src/index.js` 的推送将会触发工作流运行，但只更改 `sub-project/docs/readme.md` 的推送不会触发。\n\n```yaml\non:\n  push:\n    paths:\n      - 'sub-project/**'\n      - '!sub-project/docs/**'\n```\n\n#### Git 差异比较\n\n> \\[!NOTE]\n> 如果推送超过 1,000 项提交，或者如果 GitHub 因超时未生成差异，则工作流将始终运行。\n\n筛选器通过评估更改的文件并针对 `paths-ignore` 或 `paths` 列表运行它们来确定是否应运行工作流。 如果没有更改文件，工作流程将不会运行。\n\nGitHub 会针对推送使用双点差异，针对拉取请求使用三点差异，生成已更改文件列表：\n\n* **拉取请求：** 三点差异比较主题分支的最近版本与其中使用基本分支最新同步主题分支的提交。\n* **推送到现有分支：** 双点差异直接相互比较头部和基础 SHA。\n* **推送到新分支：** 根据已推送最深提交的上级父项的两点差异。\n\n> \\[!NOTE]\n> 差异限制为 300 个文件。 如果更改的文件与过滤器返回的前 300 个文件不匹配，工作流程将不会运行。 您可能需要创建更多的特定过滤器，以便工作流程自动运行。\n\n有关详细信息，请参阅“[关于比较拉取请求中的分支](/zh/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests)”。\n\n### 使用筛选器定位工作流程运行事件的特定分支\n\n使用 `workflow_run` 事件时，可以指定触发工作流必须在哪些分支上运行才能触发工作流。\n\n`branches` 和 `branches-ignore` 筛选器接受使用 `*`、`**`、`+`、`?` 和 `!` 等字符匹配多个分支名称的 glob 模式。 如果名称包含其中任一字符，而你想要逐字匹配，则需要使用 \\_\\_ 转义每个特殊字符。 有关 glob 模式的详细信息，请参阅“[GitHub Actions 的工作流语法](/zh/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)”。\n\n例如，仅当名为 `Build` 的工作流在名称以 `releases/` 开头的分支上运行时，具有以下触发器的工作流才会运行：\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n```\n\n仅当名为 `Build` 的工作流不在名为 `canary` 的分支上运行时，具有以下触发器的工作流才会运行：\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches-ignore:\n      - \"canary\"\n```\n\n不能对工作流中的同一事件同时使用 `branches` 和 `branches-ignore` 筛选器。 如果要同时包括和排除单个事件的分支模式，请使用 `branches` 筛选器以及 `!` 字符来指示应排除哪些分支。\n\n您定义模式事项的顺序。\n\n* 肯定匹配后的匹配否定模式（前缀为 `!`）将排除分支。\n* 否定匹配后的匹配肯定模式将再次包含分支。\n\n例如，当名为 `Build` 的工作流在名为 `releases/10` 或 `releases/beta/mona` 但不在名为 `releases/10-alpha`、`releases/beta/3-alpha` 或 `main` 的分支上运行时，具有以下触发器的工作流将运行。 <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n## 手动触发工作流程的输入定义\n\n使用 `workflow_dispatch` 事件时，你可以选择性指定传递到工作流的输入。\n\n此触发器仅当工作流文件位于默认分支时接收事件。\n触发的工作流接收 `inputs` 上下文中的输入。 有关详细信息，请参阅“[上下文](/zh/actions/learn-github-actions/contexts#inputs-context)”。\n\n> \\[!NOTE]\n>\n> * 工作流还将接收 `github.event.inputs` 上下文中的输入。\n>   `inputs` 上下文和 `github.event.inputs` 上下文中的信息完全相同，但 `inputs` 上下文将布尔值保留为布尔值，而不是将它们转换为字符串。\n>   `choice` 类型解析为字符串，是单个可选选项。\n> * 顶级属性 `inputs` 的最大数目为 25 。\n> *\n\n`inputs` 的最大有效负载为 65,535 个字符。\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      print_tags:\n        description: 'True to print to STDOUT'\n        required: true\n        type: boolean\n      tags:\n        description: 'Test scenario tags'\n        required: true\n        type: string\n      environment:\n        description: 'Environment to run tests against'\n        type: environment\n        required: true\n\njobs:\n  print-tag:\n    runs-on: ubuntu-latest\n    if: ${{ inputs.print_tags }} \n    steps:\n      - name: Print the input tag to STDOUT\n        run: echo  The tags are ${{ inputs.tags }} \n```\n\n## 定义可重复使用的工作流程的输入、输出和机密\n\n您可以定义可重用工作流程应从调用工作流程接收的输入和机密。 您还可以指定可重用工作流程将提供给调用工作流程的输出。 有关详细信息，请参阅“[重用工作流](/zh/actions/using-workflows/reusing-workflows)”。\n\n## 使用事件信息\n\n有关触发工作流运行的事件的信息可在 `github.event` 上下文中找到。 上下文中的 `github.event` 属性取决于触发工作流的事件的类型。 例如，在标记议题时触发的工作流程将包含有关议题和标签的信息。\n\n### 查看事件的所有属性\n\n有关常见属性和示例负载，请参阅 web 挂钩事件文档。 有关详细信息，请参阅“[Webhook 事件和有效负载](/zh/webhooks-and-events/webhooks/webhook-events-and-payloads)”。\n\n你还可以将整个 `github.event` 上下文打印出来，以查看哪些属性可用于触发工作流的事件：\n\n```yaml\njobs:\n  print_context:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          EVENT_CONTEXT: ${{ toJSON(github.event) }}\n        run: |\n          echo $EVENT_CONTEXT\n```\n\n### 访问和使用事件属性\n\n你可以在工作流中使用 `github.event` 上下文。 例如，以下工作流在打开更改 `package*.json`、`.github/CODEOWNERS` 或 `.github/workflows/**` 的拉取请求时运行。 如果拉取请求作者 (`github.event.pull_request.user.login`) 不是 `octobot` 或 `dependabot[bot]`，则工作流使用 GitHub CLI 来标记和注释拉取请求 (`github.event.pull_request.number`)。\n\n```yaml\non:\n  pull_request:\n    types:\n      - opened\n    paths:\n      - '.github/workflows/**'\n      - '.github/CODEOWNERS'\n      - 'package*.json'\n\njobs:\n  triage:\n    if: >-\n      github.event.pull_request.user.login != 'octobot' &&\n      github.event.pull_request.user.login != 'dependabot[bot]'\n    runs-on: ubuntu-latest\n    steps:\n      - name: \"Comment about changes we can't accept\"\n        env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          PR: ${{ github.event.pull_request.html_url }}\n        run: |\n          gh pr edit $PR --add-label 'invalid'\n          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.'\n```\n\n有关上下文的详细信息，请参阅“[上下文参考](/zh/actions/learn-github-actions/contexts)”。 有关事件负载的详细信息，请参阅“[Webhook 事件和有效负载](/zh/webhooks-and-events/webhooks/webhook-events-and-payloads)”。\n\n## 进一步控制工作流程的运行方式\n\n如果需要比事件、事件活动类型或事件筛选器更精细的控制，则可以使用条件和环境来控制工作流中的单个作业或步骤是否运行。\n\n### 使用条件语句\n\n您可以使用条件进一步控制工作流程中的作业或步骤是否运行。\n\n#### 在事件负载中使用值的示例\n\n例如，如果希望在向问题添加特定标签时运行工作流，则可以在 `issues labeled` 事件活动类型上触发，并使用条件来检查触发工作流的标签。 当在工作流的存储库中的问题上添加任何标签时，将会运行以下工作流，但是只有当标签命名为 `run_if_label_matches` 时，`bug` 任务才会被执行。\n\n```yaml\non:\n  issues:\n    types:\n      - labeled\n\njobs:\n  run_if_label_matches:\n    if: github.event.label.name == 'bug'\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo 'The label was bug'\n```\n\n#### 使用事件类型的示例\n\n例如，如果要根据触发工作流程的事件运行不同的作业或步骤，则可以使用条件来检查事件上下文中是否存在特定的事件类型。 每当议题或拉取请求关闭时，将运行以下工作流程。 如果工作流因问题已关闭而运行，则 `github.event` 上下文将包含 `issue` 的值，但不包含 `pull_request` 的值。 因此，`if_issue` 步骤将运行，但 `if_pr` 步骤不会运行。 相反，如果工作流因拉取请求关闭而运行，则 `if_pr` 步骤将运行，但 `if_issue` 步骤不会运行。\n\n```yaml\non:\n  issues:\n    types:\n      - closed\n  pull_request:\n    types:\n      - closed\n\njobs:\n  state_event_type:\n    runs-on: ubuntu-latest\n    steps:\n    - name: if_issue\n      if: github.event.issue\n      run: |\n        echo An issue was closed\n    - name: if_pr\n      if: github.event.pull_request\n      run: |\n        echo A pull request was closed\n```\n\n有关事件上下文中可用信息的详细信息，请参阅“[使用事件信息](#using-event-information)”。 有关如何使用条件的详细信息，请参阅“[对工作流和操作中的表达式求值](/zh/actions/learn-github-actions/expressions)”。\n\n### 使用环境手动触发工作流程作业\n\n如果要手动触发工作流程中的特定作业，可以使用需要特定团队或用户批准的环境。 首先，配置一个包含所需审阅者的环境。 有关详细信息，请参阅“[管理部署环境](/zh/actions/deployment/targeting-different-environments/managing-environments-for-deployment)”。 然后，使用`environment:` 键在工作流的作业中引用环境名称。 在至少有一个审阅者批准该作业之前，引用环境的任何作业都不会运行。\n\n例如，只要有推送到 main 分支，以下工作流程就会运行。\n`build` 作业将始终运行。 只有在 `build` 作业成功完成（由于 `needs: [build]`）并且称为 `production` 的环境的所有规则（包括必需的审阅者）通过（由于 `environment: production`）之后，`publish` 作业才会运行。\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - name: build\n        run: |\n          echo 'building'\n\n  publish:\n    needs: [build]\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: publish\n        run: |\n          echo 'publishing'\n```\n\n> \\[!NOTE]\n> 所有当前 GitHub 计划的公共存储库中都提供了环境、环境机密和部署保护规则。 在旧版计划中（如铜牌、银牌或金牌计划）不提供这些服务。 若要访问专用或内部存储库中的环境、环境机密和部署分支，必须使用 GitHub Pro、 GitHub Team或 GitHub Enterprise。\n> 如果你使用的是GitHub Free、GitHub Pro或GitHub Team计划，则其他部署保护规则（例如等待计时器或必需的审阅者）仅适用于公共存储库。\n\n## 可用事件\n\n有关可用事件的完整列表，请参阅“[触发工作流的事件](/zh/actions/using-workflows/events-that-trigger-workflows)”。"}