# 上下文参考 查找有关工作流中 GitHub Actions 可用的上下文的信息，包括可用属性、访问方法和用法示例。 ## 可用上下文 | 上下文名称 | 类型 | 说明 | | ---------- | -------- | ------------------------------------------------------------------- | | `github` | `object` | 有关工作流运行的信息。 有关更多信息，请参阅 [`github` 上下文](#github-context)。 | | `env` | `object` | 包含工作流、作业或步骤中设置的变量。 有关更多信息，请参阅 [`env` 上下文](#env-context)。 | | `vars` | `object` | 包含在存储库、组织或环境级别上设置的变量集。 有关更多信息，请参阅 [`vars` 上下文](#vars-context)。 | | `job` | `object` | 有关当前运行的作业的信息。 有关更多信息，请参阅 [`job` 上下文](#job-context)。 | | `jobs` | `object` | 仅适用于可重用工作流，包含可重用工作流中的作业输出。 有关更多信息，请参阅 [`jobs` 上下文](#jobs-context)。 | | `steps` | `object` | 有关当前作业中已运行的步骤的信息。 有关更多信息，请参阅 [`steps` 上下文](#steps-context)。 | | `runner` | `object` | 有关运行当前作业的运行器的信息。 有关更多信息，请参阅 [`runner` 上下文](#runner-context)。 | | `secrets` | `object` | 包含可用于工作流运行的机密的名称和值。 有关更多信息，请参阅 [`secrets` 上下文](#secrets-context)。 | | `strategy` | `object` | 有关当前作业的矩阵执行策略的信息。 有关更多信息，请参阅 [`strategy` 上下文](#strategy-context)。 | | `matrix` | `object` | 包含在工作流中定义的应用于当前作业的矩阵属性。 有关更多信息，请参阅 [`matrix` 上下文](#matrix-context)。 | | `needs` | `object` | 包含定义为当前作业依赖项的所有作业的输出。 有关更多信息，请参阅 [`needs` 上下文](#needs-context)。 | | `inputs` | `object` | 包含可重用或手动触发的工作流的输入。 有关更多信息，请参阅 [`inputs` 上下文](#inputs-context)。 | 作为表达式的一部分，您可以使用以下两种语法之一访问上下文信息。 * 索引语法：`github['sha']` * 属性取消引用语法：`github.sha` 若要使用属性取消引用语法，属性名称必须以字母或 `_` 开头，并且只能包含字母数字字符、`-` 或 `_`。 如果尝试取消引用不存在的属性，则计算结果为空字符串。 ### 确定何时使用上下文 GitHub Actions 包括名为 *上下文* 的变量的集合和称为 \_默认变量\_的类似变量集合。 这些变量预期用于工作流程中的不同点： * **默认环境变量**：这些环境变量仅存在于执行作业的运行器上。 有关详细信息，请参阅“[变量参考](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/variables)”。 * **上下文**：你可以在工作流的任何时间点使用大多数上下文，包括当\_默认变量\_不可用时。 例如，你可以使用带表达式的上下文执行初始处理，然后将作业路由到运行器以供执行；这允许你使用带有条件 `if` 关键字的上下文来确定步骤是否应运行。 作业运行后，还可以从执行作业的运行器（如 `runner.os`）检索上下文变量。 有关可在工作流中使用各种上下文的位置的详细信息，请参阅[上下文可用性](#context-availability)。 下面的示例演示了这些不同类型的变量如何在一个作业中一起使用： ```yaml copy name: CI on: push jobs: prod-check: if: ${{ github.ref == 'refs/heads/main' }} runs-on: ubuntu-latest steps: - run: echo "Deploying to production server on branch $GITHUB_REF" ``` 在此示例中，`if` 语句检查 [`github.ref`](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context) 上下文以确定当前分支名称；如果名称为 `refs/heads/main`，则执行后续步骤。 `if` 检查由 GitHub Actions 处理，仅当结果为 `true` 时作业才会发送给运行器。 将作业发送到运行器后，将执行该步骤，并引用运行器中的 [`$GITHUB_REF`](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/variables) 变量。 ### 上下文可用性 在整个工作流程运行过程中，提供不同的上下文。 例如，`secrets` 上下文只能在作业中的某些位置使用。 此外，某些功能只能在某些地方使用。 例如，`hashFiles` 函数在任何地方都不可用。 下表列出了在工作流中可以使用每个上下文和特殊函数的限制。 列出的上下文仅适用于给定的工作流密钥，不得在其他任何地方使用。 除非下面列出，否则可以在任何地方使用函数。 | 工作流密钥 | 上下文 | 特殊函数 | | -------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------ | | `run-name` | `github, inputs, vars` | 无 | | `concurrency` | `github, inputs, vars` | 无 | | `env` | `github, secrets, inputs, vars` | 无 | | `jobs..concurrency` | `github, needs, strategy, matrix, inputs, vars` | 无 | | `jobs..container` | `github, needs, strategy, matrix, vars, inputs` | 无 | | `jobs..container.credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | 无 | | `jobs..container.env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | 无 | | `jobs..container.image` | `github, needs, strategy, matrix, vars, inputs` | 无 | | `jobs..continue-on-error` | `github, needs, strategy, vars, matrix, inputs` | 无 | | `jobs..defaults.run` | `github, needs, strategy, matrix, env, vars, inputs` | 无 | | `jobs..env` | `github, needs, strategy, matrix, vars, secrets, inputs` | 无 | | `jobs..environment` | `github, needs, strategy, matrix, vars, inputs` | 无 | | `jobs..environment.url` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | 无 | | `jobs..if` | `github, needs, vars, inputs` | `always, cancelled, success, failure` | | `jobs..name` | `github, needs, strategy, matrix, vars, inputs` | 无 | | `jobs..outputs.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | 无 | | `jobs..runs-on` | `github, needs, strategy, matrix, vars, inputs` | 无 | | `jobs..secrets.` | `github, needs, strategy, matrix, secrets, inputs, vars` | 无 | | `jobs..services` | `github, needs, strategy, matrix, vars, inputs` | 无 | | `jobs..services..credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | 无 | | `jobs..services..env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | 无 | | `jobs..steps.continue-on-error` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.env` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.if` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | `always, cancelled, success, failure, hashFiles` | | `jobs..steps.name` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.run` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.timeout-minutes` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.with` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.working-directory` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..strategy` | `github, needs, vars, inputs` | 无 | | `jobs..timeout-minutes` | `github, needs, strategy, matrix, vars, inputs` | 无 | | `jobs..with.` | `github, needs, strategy, matrix, inputs, vars` | 无 | | `on.workflow_call.inputs..default` | `github, inputs, vars` | 无 | | `on.workflow_call.outputs..value` | `github, jobs, vars, inputs` | 无 | ### 示例：将上下文信息打印到日志 您可以将上下文的内容打印到日志中进行调试。 需要使用 [`toJSON` 函数](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions#tojson)才能将 JSON 对象优质打印到日志。 > \[!WARNING] > 使用整个 `github` 上下文时，请注意其中包含敏感信息，例如 `github.token`。 GitHub 在打印到控制台时会隐藏密钥，但您在导出或打印上下文时应谨慎行事。 ```yaml copy name: Context testing on: push jobs: dump_contexts_to_log: runs-on: ubuntu-latest steps: - name: Dump GitHub context env: GITHUB_CONTEXT: ${{ toJson(github) }} run: echo "$GITHUB_CONTEXT" - name: Dump job context env: JOB_CONTEXT: ${{ toJson(job) }} run: echo "$JOB_CONTEXT" - name: Dump steps context env: STEPS_CONTEXT: ${{ toJson(steps) }} run: echo "$STEPS_CONTEXT" - name: Dump runner context env: RUNNER_CONTEXT: ${{ toJson(runner) }} run: echo "$RUNNER_CONTEXT" - name: Dump strategy context env: STRATEGY_CONTEXT: ${{ toJson(strategy) }} run: echo "$STRATEGY_CONTEXT" - name: Dump matrix context env: MATRIX_CONTEXT: ${{ toJson(matrix) }} run: echo "$MATRIX_CONTEXT" ``` ## `github` 上下文 `github` 上下文包含有关工作流运行和触发运行的事件的信息。 可以在环境变量中读取大多数 `github` 上下文数据。 有关环境变量的详细信息，请参阅“[在变量中存储信息](/zh/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables)”。 > \[!WARNING] > 使用整个 `github` 上下文时，请注意其中包含敏感信息，例如 `github.token`。 GitHub 在打印到控制台时会隐藏密钥，但您在导出或打印上下文时应谨慎行事。 > \[!WARNING] > 创建工作流和操作时，应始终考虑代码是否可能执行潜在攻击者的不受信任的输入。 某些上下文应被视为不受信任的输入，因为攻击者可能会插入自己的恶意内容。 有关详细信息，请参阅“[安全使用指南](/zh/enterprise-server@3.22/actions/reference/security/secure-use#good-practices-for-mitigating-script-injection-attacks)”。 | 属性名称 | 类型 | 说明 | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `github` | `object` | 工作流中的任何作业或步骤中可用的顶级上下文。 此对象包含下面列出的所有属性。 | | `github.action` | `string` | 正在运行的操作的名称，或步骤的 [`id`](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid)。 | | GitHub删除特殊字符，并在当前步骤运行没有`__run`的脚本时使用名称`id`。 如果在同一作业中多次使用相同的操作，则名称将包含一个前面跟序号和下划线的后缀。 例如，运行的第一个脚本的名称将为 `__run`，第二个脚本的名称将为 `__run_2`。 同样，`actions/checkout` 的第二次调用将为 `actionscheckout2`。 | | | | `github.action_path` | `string` | 操作所在的路径。 此属性仅在复合操作中受支持。 可以使用此路径访问与操作位于同一存储库中的文件，例如，将目录更改为路径（使用相应的环境变量）： `cd "$GITHUB_ACTION_PATH"` 有关环境变量的详细信息，请参阅 [安全使用指南](/zh/enterprise-server@3.22/actions/reference/security/secure-use#use-an-intermediate-environment-variable)。 | | `github.action_ref` | `string` | 对于执行操作的步骤，这是正在执行的操作的引用。 例如，`v2`。

不要在 `run` 关键字中使用。 若要使此上下文适用于复合操作，请在复合操作的 `env` 上下文中引用它。 | | `github.action_repository` | `string` | 对于执行操作的步骤，这是操作的所有者和存储库名称。 例如，`actions/checkout`。

不要在 `run` 关键字中使用。 若要使此上下文适用于复合操作，请在复合操作的 `env` 上下文中引用它。 | | `github.action_status` | `string` | 对于复合操作，这是复合操作的当前结果。 | | `github.actor` | `string` | 触发初始工作流运行的用户的用户名。 如果工作流运行是重新运行，则此值可能与 `github.triggering_actor` 不同。 即使启动重新运行的参与者 (`github.actor`) 具有不同的权限，任何工作流重新运行都将使用 `github.triggering_actor` 的权限。 | | `github.actor_id` | `string` | 触发初始工作流运行的个人或应用的帐户 ID。 例如 `1234567`。 请注意，这与参与者用户名不同。 | | `github.api_url` | `string` | REST API 的 GitHub URL。 | | | | | | `github.artifacts` | `string` | 运行程序的路径，该文件标识当前步骤的工作流项目。 每行编写一个声明，以将文件或 OCI 摘要引用标识为工作流项目。 有关详细信息，请参阅“[GitHub Actions 的工作流命令](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#declaring-workflow-artifacts)”。 | | `github.artifacts_list` | `string` | 运行程序的路径，该文件包含当前作业的聚合工作流项目元数据作为 JSON。 有关详细信息，请参阅“[GitHub Actions 的工作流命令](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#reading-workflow-artifacts)”。 | | | | | | `github.base_ref` | `string` | 工作流运行中拉取请求的 `base_ref` 或目标分支。 仅当触发工作流运行的事件是 `pull_request` 或 `pull_request_target` 时，才可使用此属性。 | | `github.env` | `string` | 运行器上从工作流程命令到设置环境变量的文件路径。 此文件对于当前步骤是唯一的，并且是作业中每个步骤的不同文件。 有关详细信息，请参阅“[GitHub Actions 的工作流命令](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#setting-an-environment-variable)”。 | | `github.event` | `object` | 完整事件 web 挂钩有效负载。 您可以使用上下文访问事件的个别属性。 此对象与触发工作流运行的事件的 web 挂钩有效负载相同，并且对于每个事件都是不同的。 每个 GitHub Actions 事件的 Webhook 在 [触发工作流的事件](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_call) 中链接。 例如，对于由 [`push` 事件](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#push)触发的工作流运行，此对象包含[推送 webhook 有效负载](/zh/enterprise-server@3.22/webhooks/webhook-events-and-payloads#push)的内容。 | | `github.event_name` | `string` | 触发工作流程运行的事件的名称。 | | `github.event_path` | `string` | 运行器上包含完整事件 web 挂钩负载的文件的路径。 | | `github.graphql_url` | `string` | GraphQL API 的 GitHub URL。 | | `github.head_ref` | `string` | 工作流程运行中拉取请求的 `head_ref` 或来源分支。 仅当触发工作流运行的事件是 `pull_request` 或 `pull_request_target` 时，才可使用此属性。 | | `github.job` | `string` | 当前作业的 [`job_id`](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_id)。
注意：此上下文属性是由 Actions 运行程序设置的，仅在作业的执行 `steps` 中可用。 否则，此属性的值将为 `null`。 | | `github.path` | `string` | 运行器上从工作流命令设置系统 `PATH` 变量的文件的路径。 此文件对于当前步骤是唯一的，并且是作业中每个步骤的不同文件。 有关详细信息，请参阅“[GitHub Actions 的工作流命令](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#adding-a-system-path)”。 | | `github.ref` | `string` | 触发工作流运行的分支或标记的格式完整的参考。 对于 `push` 触发的工作流，这是被推送的分支或标签引用。 对于未合并的 `pull_request` 工作流，这是拉取请求合并分支。 如果 Pull Request 已合并，这是其被合并到的分支。 对于由 `release` 触发的工作流，这是创建的发布标记。 对于其他触发器，这是触发工作流运行的分支或标签引用。 此变量仅在分支或标记可用于事件类型时才会设置。 给出的引用格式是完整的，这意味着对于分支，其格式为 `refs/heads/`。 对于未合并的拉取请求事件（除了 `pull_request_target`），为 `refs/pull//merge`。 | | `pull_request_target` 事件具有基础分支中的 `ref`。 对于标记，格式为 `refs/tags/`。 例如，`refs/heads/feature-branch-1`。 有关拉取请求合并分支的详细信息，请参阅 [拉取请求](/zh/enterprise-server@3.22/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches)。 | | | | `github.ref_name` | `string` | 触发工作流运行的分支或标记的短参考名称。 此值与 GitHub 上显示的分支或标记名称匹配。 例如，`feature-branch-1`。

对于未合并的拉取请求，格式为 `/merge`。 | | `github.ref_protected` | `boolean` | 如果为触发工作流运行的 ref 配置分支保护 ，则为 `true`。 | | `github.ref_type` | `string` | 触发工作流运行的 ref 类型。 有效值为 `branch` or `tag`。 | | `github.repository` | `string` | 所有者和仓库名称。 例如，`octocat/Hello-World`。 | | `github.repository_id` | `string` | 存储库的 ID。 例如 `123456789`。 请注意，这与存储库名称不同。 | | `github.repository_owner` | `string` | 存储库所有者的用户名。 例如，`octocat`。 | | `github.repository_owner_id` | `string` | 存储库所有者的帐户 ID。 例如 `1234567`。 请注意，这与所有者名称不同。 | | `github.repositoryUrl` | `string` | 存储库的 Git URL。 例如，`git://github.com/octocat/hello-world.git`。 | | `github.retention_days` | `string` | 工作流运行日志和项目保留的天数。 | | `github.run_id` | `string` | 存储库中每个工作流运行的唯一编号。 如果您重新执行工作流程运行，此编号不变。 | | `github.run_number` | `string` | 仓库中特定工作流程每个运行的唯一编号。 工作流首次运行时，此编号从 1 开始，并随着每次新的运行而递增。 如果您重新执行工作流程运行，此编号不变。 | | `github.run_attempt` | `string` | 存储库中每次尝试运行特定工作流的唯一编号。 对于工作流程运行的第一次尝试，此数字从 1 开始，并随着每次重新运行而递增。 | | `github.secret_source` | `string` | 工作流中使用的机密的来源。 可能的值为 `None`、 `Actions`或 `Dependabot`。 | | `github.server_url` | `string` | GitHub 服务器的 URL。 例如：`https://github.com`。 | | `github.sha` | `string` | 触发工作流的提交 SHA。 此提交 SHA 的值取决于触发工作流程的事件。 有关详细信息，请参阅“[触发工作流的事件](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows)”。 例如，`ffac537e6cbbf934b08745a378932722df287a53`。 | | `github.token` | `string` | 代表存储库中安装的 GitHub 应用程序进行身份验证的令牌。 在功能上，这与 `GITHUB_TOKEN` 机密等效。 有关详细信息，请参阅“[在工作流中使用 GITHUB\_TOKEN 进行身份验证](/zh/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token)”。
注意：此上下文属性是由 Actions 运行程序设置的，仅在作业的执行 `steps` 中可用。 否则，此属性的值将为 `null`。 | | `github.triggering_actor` | `string` | 发起工作流运行的用户的用户名。 如果工作流运行是重新运行，则此值可能与 `github.actor` 不同。 即使启动重新运行的参与者 (`github.triggering_actor`) 具有不同的权限，任何工作流重新运行都将使用 `github.actor` 的权限。 | | `github.workflow` | `string` | 工作流的名称。 如果工作流程文件未指定 `name`，则此属性的值是存储库中工作流程文件的完整路径。 | | `github.workflow_ref` | `string` | 工作流的引用路径。 例如，`octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch`。 | | `github.workflow_sha` | `string` | 工作流文件的提交 SHA。 | | `github.workspace` | `string` | 运行器上步骤的默认工作目录，以及使用 [`checkout`](https://github.com/actions/checkout) 操作时存储库的默认位置。 | ### `github` 上下文的示例内容 以下示例上下文来自 `push` 事件触发的工作流运行。 此示例中的 `event` 对象已被截断，因为它与 [`push` webhook 有效负载](/zh/enterprise-server@3.22/webhooks/webhook-events-and-payloads#push)的内容相同。 > \[!NOTE] > 此上下文只是一个示例。 上下文的内容取决于正在运行的工作流。 在不同的工作流运行条件下，上下文、对象和属性大不相同。 ```json { "token": "***", "job": "dump_contexts_to_log", "ref": "refs/heads/my_branch", "sha": "c27d339ee6075c1f744c5d4b200f7901aad2c369", "repository": "octocat/hello-world", "repository_owner": "octocat", "repositoryUrl": "git://github.com/octocat/hello-world.git", "run_id": "1536140711", "run_number": "314", "retention_days": "90", "run_attempt": "1", "actor": "octocat", "workflow": "Context testing", "head_ref": "", "base_ref": "", "event_name": "push", "event": { ... }, "server_url": "https://github.com", "api_url": "https://api.github.com", "graphql_url": "https://api.github.com/graphql", "ref_name": "my_branch", "ref_protected": false, "ref_type": "branch", "secret_source": "Actions", "workspace": "/home/runner/work/hello-world/hello-world", "action": "github_step", "event_path": "/home/runner/work/_temp/_github_workflow/event.json", "action_repository": "", "action_ref": "", "path": "/home/runner/work/_temp/_runner_file_commands/add_path_b037e7b5-1c88-48e2-bf78-eaaab5e02602", "env": "/home/runner/work/_temp/_runner_file_commands/set_env_b037e7b5-1c88-48e2-bf78-eaaab5e02602" } ``` ### `github` 上下文的示例用法 此示例工作流仅当工作流运行由 `github.event_name` 事件触发时才使用 `pull_request` 上下文运行作业。 ```yaml copy name: Run CI on: [push, pull_request] jobs: normal_ci: runs-on: ubuntu-latest steps: - name: Run normal CI run: echo "Running normal CI" pull_request_ci: runs-on: ubuntu-latest if: ${{ github.event_name == 'pull_request' }} steps: - name: Run PR CI run: echo "Running PR only CI" ``` ## `env` 上下文 `env` 上下文包含已在工作流、作业或步骤中设置的变量。 它不包含运行器进程继承的变量。 有关在工作流中设置变量的详细信息，请参阅 [GitHub Actions 的工作流语法](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#env)。 可以检索存储在 `env` 上下文中的变量的值，并在工作流文件中使用这些值。 可以在非 `env` 和 `id` 键的工作流程步骤中，在任何键中使用 `uses` 上下文。 有关步骤语法的详细信息，请参阅 [GitHub Actions 的工作流语法](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsteps)。 如果想要在运行器中使用变量的值，请使用运行器操作系统的正常方法来读取环境变量。 | 属性名称 | 类型 | 说明 | | ---------------- | -------- | ---------------------------------------------------- | | `env` | `object` | 此上下文针对作业中的每个步骤而改变。 您可以从作业中的任何步骤访问此上下文。 此对象包含下面列出的属性。 | | `env.` | `string` | 特定环境变量的值。 | ### `env` 上下文的示例内容 `env` 上下文的内容是变量名称与其值的映射。 上下文的内容可能会根据工作流运行中的使用位置而更改。 在此示例中，`env` 上下文包含两个变量。 ```json { "first_name": "Mona", "super_duper_var": "totally_awesome" } ``` ### `env` 上下文的示例用法 此示例工作流显示了在工作流、作业和步骤级别的 `env` 上下文中设置的变量。 然后，该 `${{ env.VARIABLE-NAME }}` 语法用于检索工作流中各个步骤的变量值。 当多个环境变量使用相同的名称定义时，GitHub 会使用最特定的变量。 例如，步骤中定义的环境变量在步骤执行时将覆盖名称相同的作业和工作流环境变量。 为作业定义的环境变量在作业执行时将覆盖名称相同的工作流变量。 ```yaml copy name: Hi Mascot on: push env: mascot: Mona super_duper_var: totally_awesome jobs: windows_job: runs-on: windows-latest steps: - run: echo 'Hi ${{ env.mascot }}' # Hi Mona - run: echo 'Hi ${{ env.mascot }}' # Hi Octocat env: mascot: Octocat linux_job: runs-on: ubuntu-latest env: mascot: Tux steps: - run: echo 'Hi ${{ env.mascot }}' # Hi Tux ``` ## `vars` 上下文 `vars` 上下文包含在组织、存储库和环境级别设置的自定义配置变量。 有关定义用于多个工作流的配置变量的详细信息，请参阅 [在变量中存储信息](/zh/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables#defining-configuration-variables-for-multiple-workflows)。 ### `vars` 上下文的示例内容 `vars` 上下文的内容是配置变量名称与其值的映射。 ```json { "mascot": "Mona" } ``` ### `vars` 上下文的示例用法 此示例工作流演示如何使用 `vars` 上下文自动提供在存储库、环境或组织级别设置的配置变量。 > \[!NOTE] > 运行器声明环境后，环境级别的配置变量会自动可用。 如果尚未设置配置变量，则引用该变量的上下文的返回值将为空字符串。 以下示例演示如何在工作流中将配置变量与 `vars` 上下文配合使用。 以下每个配置变量都已在存储库、组织或环境级别上定义。 ```yaml copy on: workflow_dispatch: env: # Setting an environment variable with the value of a configuration variable env_var: ${{ vars.ENV_CONTEXT_VAR }} jobs: display-variables: name: ${{ vars.JOB_NAME }} # You can use configuration variables with the `vars` context for dynamic jobs if: ${{ vars.USE_VARIABLES == 'true' }} runs-on: ${{ vars.RUNNER }} environment: ${{ vars.ENVIRONMENT_STAGE }} steps: - name: Use variables run: | echo "repository variable : $REPOSITORY_VAR" echo "organization variable : $ORGANIZATION_VAR" echo "overridden variable : $OVERRIDE_VAR" echo "variable from shell environment : $env_var" env: REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }} ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }} OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }} - name: ${{ vars.HELLO_WORLD_STEP }} if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }} uses: actions/hello-world-javascript-action@main with: who-to-greet: ${{ vars.GREET_NAME }} ``` ## `job` 上下文 `job` 上下文包含当前正在运行的作业相关信息。 | 属性名称 | 类型 | 说明 | | ----------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `job` | `object` | 此上下文针对工作流程运行中的每项作业而改变。 您可以从作业中的任何步骤访问此上下文。 此对象包含下面列出的所有属性。 | | | | | | `job.container` | `object` | 作业的容器相关信息。 有关容器的详细信息，请参阅 [GitHub Actions 的工作流语法](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idcontainer)。 | | `job.container.id` | `string` | 容器的 ID。 | | `job.container.network` | `string` | 容器网络的 ID。 运行程序创建作业中所有容器使用的网络。 | | `job.services` | `object` | 为作业创建的服务容器。 有关服务容器的详细信息，请参阅 [GitHub Actions 的工作流语法](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idservices)。 | | `job.services..id` | `string` | 服务容器的 ID。 | | `job.services..network` | `string` | 服务容器网络的 ID。 运行程序创建作业中所有容器使用的网络。 | | `job.services..ports` | `object` | 服务容器显露的端口。 | | `job.status` | `string` | 作业的当前状态。 可能的值为 `success`、`failure` 或 `cancelled`。 | | `job.workflow_ref` | `string` | 定义当前作业的工作流文件的完整引用。 例如，`octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main`。 对于直接在工作流文件中定义的作业，这与 `github.workflow_ref` 是相同的。 对于 [重用工作流](/zh/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) 中定义的作业，这指的是可重用的工作流文件。 未在 GitHub Enterprise Server 上可用 | | `job.workflow_sha` | `string` | 定义当前作业的工作流文件的提交 SHA。 未在 GitHub Enterprise Server 上可用 | | `job.workflow_repository` | `string` | 定义当前作业的工作流文件所在的`owner/repo`存储库。 例如，`octo-org/octo-repo`。 未在 GitHub Enterprise Server 上可用 | | `job.workflow_file_path` | `string` | 定义当前作业的工作流文件相对于存储库根的文件路径。 例如，`.github/workflows/deploy.yml`。 未在 GitHub Enterprise Server 上可用 | ### `job` 上下文的示例内容 此示例 `job` 上下文使用具有映射端口的 PostgreSQL 服务容器。 如果作业中没有容器或服务容器，则 `job` 上下文仅包含 `status`。 `check_run_id`和工作流标识属性（`workflow_ref`、`workflow_sha`、`workflow_repository`、`workflow_file_path`）在GitHub Enterprise Server上不可用。 ```json { "status": "success", "check_run_id": 51725241954, "workflow_ref": "octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main", "workflow_sha": "abc123def456789abc123def456789abc123def4", "workflow_repository": "octo-org/octo-repo", "workflow_file_path": ".github/workflows/deploy.yml", "container": { "network": "github_network_53269bd575974817b43f4733536b200c" }, "services": { "postgres": { "id": "60972d9aa486605e66b0dad4abb638dc3d9116f566579e418166eedb8abb9105", "ports": { "5432": "49153" }, "network": "github_network_53269bd575974817b43f4733536b200c" } } } ``` ### `job` 上下文的示例用法 此示例工作流程配置 PostgreSQL 服务容器，并自动将服务容器中的端口 5432 映射到主机上随机选择的可用端口。 `job` 上下文用于访问在主机上分配的端口号。 ```yaml copy name: PostgreSQL Service Example on: push jobs: postgres-job: runs-on: ubuntu-latest services: postgres: image: postgres env: POSTGRES_PASSWORD: postgres options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5 ports: # Maps TCP port 5432 in the service container to a randomly chosen available port on the host. - 5432 steps: - run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }} - run: echo "Run tests against Postgres" ``` ### 上下文工作流标识的示例用法`job` > \[!NOTE] > `job.workflow_*` 上下文属性在 GitHub Enterprise Server 上不可用。 此示例可重用工作流使用 `job.workflow_repository` 和 `job.workflow_sha` 签出自身的源代码，而不是调用方存储库。 当可重用的工作流需要访问与工作流定义并置的文件时，这非常有用。 ```yaml copy # In a reusable workflow (e.g., octo-org/shared-workflows/.github/workflows/deploy.yml) name: Reusable deploy workflow on: workflow_call: jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 with: repository: ${{ job.workflow_repository }} ref: ${{ job.workflow_sha }} - run: echo "Deploying from ${{ job.workflow_ref }}" - run: echo "Workflow file path is ${{ job.workflow_file_path }}" ``` ## `jobs` 上下文 `jobs` 上下文仅在可重用工作流中可用，并且只能用于设置可重用工作流的输出。 有关详细信息，请参阅“[重用工作流](/zh/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow)”。 | 属性名称 | 类型 | 说明 | | ------------------------------------- | -------- | ---------------------------------------------------------------- | | `jobs` | `object` | 这仅在可重用工作流中使用，并且只能用于设置可重用工作流的输出。 此对象包含下面列出的所有属性。 | | `jobs..result` | `string` | 可重用工作流中作业的结果。 可能的值为 `success`、`failure`、`cancelled` 或 `skipped`。 | | `jobs..outputs` | `object` | 可重用工作流中作业的输出集。 | | `jobs..outputs.` | `string` | 可重用工作流中作业的特定输出值。 | ### `jobs` 上下文的示例内容 此示例 `jobs` 上下文包含可重用工作流运行中作业的结果和输出。 ```json { "example_job": { "result": "success", "outputs": { "output1": "hello", "output2": "world" } } } ``` ### `jobs` 上下文的示例用法 此示例可重用工作流使用 `jobs` 上下文设置可重用工作流的输出。 请注意输出如何从步骤流向作业，然后流向 `workflow_call` 触发器。 有关详细信息，请参阅“[重用工作流](/zh/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow)”。 ```yaml copy name: Reusable workflow on: workflow_call: # Map the workflow outputs to job outputs outputs: firstword: description: "The first output string" value: ${{ jobs.example_job.outputs.output1 }} secondword: description: "The second output string" value: ${{ jobs.example_job.outputs.output2 }} jobs: example_job: name: Generate output runs-on: ubuntu-latest # Map the job outputs to step outputs outputs: output1: ${{ steps.step1.outputs.firstword }} output2: ${{ steps.step2.outputs.secondword }} steps: - id: step1 run: echo "firstword=hello" >> $GITHUB_OUTPUT - id: step2 run: echo "secondword=world" >> $GITHUB_OUTPUT ``` ## `steps` 上下文 `steps` 上下文包含有关当前作业中已指定 [`id`](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid) 且已运行的步骤的信息。 | 属性名称 | 类型 | 说明 | | --------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `steps` | `object` | 此上下文针对作业中的每个步骤而改变。 您可以从作业中的任何步骤访问此上下文。 此对象包含下面列出的所有属性。 | | `steps..outputs` | `object` | 为步骤定义的输出集。 有关详细信息，请参阅“[元数据语法参考](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#outputs-for-docker-container-and-javascript-actions)”。 | | `steps..conclusion` | `string` | 应用 [`continue-on-error`](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepscontinue-on-error) 后完成的步骤的结果。 可能的值为 `success`、`failure`、`cancelled` 或 `skipped`。 当 `continue-on-error` 步骤失败时，`outcome` 是 `failure`，但最终 `conclusion` 是 `success`。 | | `steps..outcome` | `string` | 应用 [`continue-on-error`](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepscontinue-on-error) 前完成的步骤的结果。 可能的值为 `success`、`failure`、`cancelled` 或 `skipped`。 当 `continue-on-error` 步骤失败时，`outcome` 是 `failure`，但最终 `conclusion` 是 `success`。 | | `steps..outputs.` | `string` | 特定输出的值。 | ### `steps` 上下文的示例内容 此示例 `steps` 上下文显示已指定 [`id`](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid) 的前两个步骤。 第一步的 `id` 名为 `checkout`，第二步是 `generate_number`。 `generate_number` 步骤的输出名为 `random_number`。 ```json { "checkout": { "outputs": {}, "outcome": "success", "conclusion": "success" }, "generate_number": { "outputs": { "random_number": "1" }, "outcome": "success", "conclusion": "success" } } ``` ### `steps` 上下文的示例用法 此示例工作流在一个步骤中生成一个随机数作为输出，后面的步骤使用 `steps` 上下文来读取该输出的值。 ```yaml copy name: Generate random failure on: push jobs: randomly-failing-job: runs-on: ubuntu-latest steps: - name: Generate 0 or 1 id: generate_number run: echo "random_number=$(($RANDOM % 2))" >> $GITHUB_OUTPUT - name: Pass or fail run: | if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi ``` ## `runner` 上下文 `runner` 上下文包含正在执行当前作业的运行器相关信息。 | 属性名称 | 类型 | 说明 | | -------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `runner` | `object` | 此上下文针对工作流程运行中的每项作业而改变。 此对象包含下面列出的所有属性。 | | `runner.name` | `string` | 执行作业的运行器的名称。 此名称在工作流运行中可能并不唯一，因为存储库和组织级别的运行器可以使用同一名称。 | | `runner.os` | `string` | 执行作业的运行器的操作系统。 可能的值为 `Linux`、`Windows` 或 `macOS`。 | | `runner.arch` | `string` | 执行作业的运行器的体系结构。 可能的值为 `X86`、`X64`、`ARM` 或 `ARM64`。 | | `runner.temp` | `string` | 运行器临时目录的路径。 此目录在每个作业的开始和结束时都是空的。 注意，如果运行者的用户帐户没有权限删除这些文件，则不会被删除。 | | `runner.tool_cache` | `string` | 包含用于 GitHub 托管的运行器的预安装工具的目录路径。 有关详细信息，请参阅“[GitHub 托管的运行程序](/zh/enterprise-server@3.22/actions/concepts/runners/github-hosted-runners#preinstalled-software-for-github-owned-images)”。 | | `runner.debug` | `string` | 仅当启用[调试日志记录](/zh/enterprise-server@3.22/actions/how-tos/monitor-workflows/enable-debug-logging)并且始终具有值 `1` 时，才会进行此设置。 它可以用作指示器，以便在自己的作业步骤中启用更多调试或详细日志记录。 | | `runner.environment` | `string` | 执行作业的运行器的环境。 可能的值包括：对于 GitHub 提供的 GitHub 托管的运行器为 `github-hosted`，对于存储库所有者配置的自承载运行器为 `self-hosted`。 | ### `runner` 上下文的示例内容 以下示例上下文来自 Linux GitHub托管的运行程序。 ```json { "os": "Linux", "arch": "X64", "name": "GitHub Actions 2", "tool_cache": "/opt/hostedtoolcache", "temp": "/home/runner/work/_temp" } ``` ### `runner` 上下文的示例用法 此示例工作流使用 `runner` 上下文来设置临时目录的路径以写入日志，如果工作流失败，它将这些日志上传为项目。 ```yaml copy name: Build on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - name: Build with logs run: | mkdir ${{ runner.temp }}/build_logs echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs exit 1 - name: Upload logs on fail if: ${{ failure() }} uses: actions/upload-artifact@v3 with: name: Build failure logs path: ${{ runner.temp }}/build_logs ``` ## `secrets` 上下文 `secrets` 上下文包含可用于工作流运行的机密的名称和值。 出于安全原因，上下文 `secrets` 不适用于复合操作。 如果要将机密传递给复合操作，则需要将其作为输入显式传递。 有关机密的详细信息，请参阅“[在 GitHub Actions 中使用机密](/zh/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets)”。 `GITHUB_TOKEN` 是为每个工作流运行自动创建的机密，始终包含在 `secrets` 上下文中。 有关详细信息，请参阅“[在工作流中使用 GITHUB\_TOKEN 进行身份验证](/zh/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token)”。 > \[!WARNING] > 如果在工作流作业中使用了机密，GitHub 会自动对输出到日志中的机密进行编辑。 应避免故意将机密输出到日志中。 | 属性名称 | 类型 | 说明 | | ----------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `secrets` | `object` | 对于工作流程运行中的每个作业，此上下文都是相同的。 您可以从作业中的任何步骤访问此上下文。 此对象包含下面列出的所有属性。 | | `secrets.GITHUB_TOKEN` | `string` | 为每个工作流程运行自动创建的令牌。 有关详细信息，请参阅“[在工作流中使用 GITHUB\_TOKEN 进行身份验证](/zh/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token)”。 | | `secrets.` | `string` | 特定机密的值。 | ### `secrets` 上下文的示例内容 `secrets` 上下文的以下示例内容显示自动 `GITHUB_TOKEN`，以及可用于工作流运行的两个其他机密。 ```json { "github_token": "***", "NPM_TOKEN": "***", "SUPERSECRET": "***" } ``` ### `secrets` 上下文的示例用法 此示例工作流程使用 [GitHub CLI](/zh/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-github-cli)，该方式需要 `GITHUB_TOKEN` 作为 `GH_TOKEN` 输入参数的值： ```yaml copy name: Open new issue on: workflow_dispatch jobs: open-issue: runs-on: ubuntu-latest permissions: contents: read issues: write steps: - run: | gh issue --repo ${{ github.repository }} \ create --title "Issue title" --body "Issue body" env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` ## `strategy` 上下文 对于具有矩阵的工作流，`strategy` 上下文包含有关当前作业的矩阵执行策略的信息。 | 属性名称 | 类型 | 说明 | | ------------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `strategy` | `object` | 此上下文针对工作流程运行中的每项作业而改变。 您可以从工作流程中的任何作业或步骤访问此上下文。 此对象包含下面列出的所有属性。 | | `strategy.fail-fast` | `boolean` | 如果此计算结果为 `true`，那么当矩阵中的任何作业失败时，将会取消所有正在进行的作业。 有关详细信息，请参阅“[GitHub Actions 的工作流语法](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategyfail-fast)”。 | | `strategy.job-index` | `number` | 矩阵中当前作业的索引。 | | **注意：** 此数字是从零开始的数字。 矩阵中的第一个作业索引为 `0`。 | | | | `strategy.job-total` | `number` | 矩阵中的作业总数。 | | **注意：** 此数字**不是**从零开始的数字。 例如，对于具有四个作业的矩阵，`job-total` 的值为 `4`。 | | | | `strategy.max-parallel` | `number` | 使用 `matrix` 作业策略时可以同时运行的最大作业数。 有关详细信息，请参阅“[GitHub Actions 的工作流语法](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategymax-parallel)”。 | ### `strategy` 上下文的示例内容 `strategy` 上下文的以下示例内容来自具有四个作业的矩阵，取自最终作业。 请注意从零开始的 `job-index` 数字与 `job-total`（不从零开始）之间的差异。 ```json { "fail-fast": true, "job-index": 3, "job-total": 4, "max-parallel": 4 } ``` ### `strategy` 上下文的示例用法 此示例工作流使用 `strategy.job-index` 属性为矩阵中的每个作业设置日志文件的唯一名称。 ```yaml copy name: Test strategy on: push jobs: test: runs-on: ubuntu-latest strategy: matrix: test-group: [1, 2] node: [14, 16] steps: - run: echo "Mock test logs" > test-job-${{ strategy.job-index }}.txt - name: Upload logs uses: actions/upload-artifact@v3 with: name: Build log for job ${{ strategy.job-index }} path: test-job-${{ strategy.job-index }}.txt ``` ## `matrix` 上下文 对于具有矩阵的工作流，`matrix` 上下文包含工作流程文件中定义的适用于当前作业的矩阵属性。 例如，如果使用 `os` 和 `node` 键配置矩阵，则 `matrix` 上下文对象包含 `os` 和 `node` 属性，该属性具有用于当前作业的值。 `matrix` 上下文中没有标准属性，只有工作流文件中定义的属性。 | 属性名称 | 类型 | 说明 | | ------------------------ | -------- | ---------------------------------------------------------------------------- | | `matrix` | `object` | 此上下文仅适用于矩阵中的作业，并且对于工作流运行中的每个作业都会发生更改。 您可以从工作流程中的任何作业或步骤访问此上下文。 此对象包含下面列出的属性。 | | `matrix.` | `string` | 矩阵属性的值。 | ### `matrix` 上下文的示例内容 `matrix` 上下文的以下示例内容来自具有工作流中定义的 `os` 和 `node` 矩阵属性的矩阵中的作业。 该作业正在执行 `ubuntu-latest` OS 和 Node.js 版本 `16` 的矩阵合并。 ```json { "os": "ubuntu-latest", "node": 16 } ``` ### `matrix` 上下文的示例用法 此示例工作流创建包含 `os` 和 `node` 键的矩阵。 它使用 `matrix.os` 属性为每个作业设置运行器类型，并使用 `matrix.node` 属性为每个作业设置 Node.js 版本。 ```yaml copy name: Test matrix on: push jobs: build: runs-on: ${{ matrix.os }} strategy: matrix: os: [ubuntu-latest, windows-latest] node: [14, 16] steps: - uses: actions/setup-node@v7 with: node-version: ${{ matrix.node }} - name: Output node version run: node --version ``` ## `needs` 上下文 `needs` 上下文包含定义为当前作业直接依赖项的所有作业的输出。 请注意，这不包括隐式依赖作业（例如依赖作业的依赖作业）。 有关如何定义作业依赖项的详细信息，请参阅 [GitHub Actions 的工作流语法](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds)。 | 属性名称 | 类型 | 说明 | | -------------------------------------- | -------- | ------------------------------------------------------------------------------------ | | `needs` | `object` | 仅为具有相关作业的工作流程运行填充此上下文，并为工作流程运行中的每个作业填充此上下文。 您可以从工作流程中的任何作业或步骤访问此上下文。 此对象包含下面列出的所有属性。 | | `needs.` | `object` | 当前作业依赖的单个作业。 | | `needs..outputs` | `object` | 当前作业依赖的作业的输出集。 | | `needs..outputs.` | `string` | 当前作业依赖的作业的特定输出值。 | | `needs..result` | `string` | 当前作业依赖的作业的结果。 可能的值为 `success`、`failure`、`cancelled` 或 `skipped`。 | ### `needs` 上下文的示例内容 `needs` 上下文的以下示例内容显示了当前作业所依赖的两个作业的信息。 ```json { "build": { "result": "success", "outputs": { "build_id": "123456" } }, "deploy": { "result": "failure", "outputs": {} } } ``` ### `needs` 上下文的示例用法 此示例工作流有三个作业：一个 `build` 作业（执行生成），一个 `deploy` 作业（需要 `build` 作业）以及一个 `debug` 作业（需要 `build` 和 `deploy` 作业且仅当工作流中有故障时运行）。 `deploy` 作业还使用 `needs` 上下文来访问 `build` 作业中的输出。 ```yaml copy name: Build and deploy on: push jobs: build: runs-on: ubuntu-latest outputs: build_id: ${{ steps.build_step.outputs.build_id }} steps: - name: Build id: build_step run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT deploy: needs: build runs-on: ubuntu-latest steps: - run: echo "Deploying build ${{ needs.build.outputs.build_id }}" debug: needs: [build, deploy] runs-on: ubuntu-latest if: ${{ failure() }} steps: - run: echo "Failed to build and deploy" ``` ## `inputs` 上下文 `inputs` 上下文包含传递给操作、可重用工作流或手动触发的工作流的输入属性。 对于可重用工作流，输入名称和类型是在可重用工作流的 [`workflow_call` 事件配置](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows)中定义的，输入值从调用可重用工作流的外部工作流中的 [`jobs..with`](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idwith) 传递。 对于手动触发的工作流，输入是在工作流的 [`workflow_dispatch` 事件配置](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch)中定义的。 `inputs` 上下文中的属性在工作流文件中定义。 它们仅在[可重用工作流](/zh/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows)或 [`workflow_dispatch` 事件](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch)触发的工作流中可用 | 属性名称 | 类型 | 说明 | | ------------------------------------------ | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `inputs` | `object` | 此上下文仅在[可重用工作流](/zh/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows)或 [`workflow_dispatch` 事件](/zh/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch)触发的工作流中可用。 您可以从工作流程中的任何作业或步骤访问此上下文。 此对象包含下面列出的属性。 | | `inputs.` | | | | `string` 或 `number` 或 `boolean` 或 `choice` | 从外部工作流传递的每个输入值。 | | ### `inputs` 上下文的示例内容 `inputs` 上下文的以下示例内容来自已定义 `build_id`、`deploy_target` 和 `perform_deploy` 输入的工作流。 ```json { "build_id": 123456768, "deploy_target": "deployment_sys_1a", "perform_deploy": true } ``` ### 可重用工作流中 `inputs` 上下文的示例用法 此示例可重用工作流使用 `inputs` 上下文从调用方工作流获取传递到可重用工作流的 `build_id`、`deploy_target` 和 `perform_deploy` 输入的值。 ```yaml copy name: Reusable deploy workflow on: workflow_call: inputs: build_id: required: true type: number deploy_target: required: true type: string perform_deploy: required: true type: boolean jobs: deploy: runs-on: ubuntu-latest if: ${{ inputs.perform_deploy }} steps: - name: Deploy build to target run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}" ``` ### 手动触发的工作流中 `inputs` 上下文的示例用法 这个由 `workflow_dispatch` 事件触发的示例工作流使用 `inputs` 上下文来获取传递给工作流的 `build_id`、`deploy_target` 和 `perform_deploy` 输入的值。 ```yaml copy on: workflow_dispatch: inputs: build_id: required: true type: string deploy_target: required: true type: string perform_deploy: required: true type: boolean jobs: deploy: runs-on: ubuntu-latest if: ${{ inputs.perform_deploy }} steps: - name: Deploy build to target run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}" ``` ## 其他阅读材料 * [上下文](/zh/enterprise-server@3.22/actions/concepts/workflows-and-actions/contexts)