{"meta":{"title":"在变量中存储信息","intro":"GitHub 为每个 GitHub Actions 工作流运行设置默认变量。 你还可以设置自定义变量，以便在单个工作流或多个工作流中使用。","product":"GitHub Actions","breadcrumbs":[{"href":"/zh/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/zh/enterprise-cloud@latest/actions/how-tos","title":"操作方法"},{"href":"/zh/enterprise-cloud@latest/actions/how-tos/write-workflows","title":"编写工作流"},{"href":"/zh/enterprise-cloud@latest/actions/how-tos/write-workflows/choose-what-workflows-do","title":"选择工作流执行的操作"},{"href":"/zh/enterprise-cloud@latest/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables","title":"使用变量"}],"documentType":"article"},"body":"# 在变量中存储信息\n\nGitHub 为每个 GitHub Actions 工作流运行设置默认变量。 你还可以设置自定义变量，以便在单个工作流或多个工作流中使用。\n\n## 为单个工作流定义环境变量\n\n若要设置单个工作流的自定义环境变量，可以在工作流文件中使用 `env` 键进行定义。 此方法设置的自定义变量的作用域仅限于在其中定义它的元素。 可以定义作用域如下的变量：\n\n* 整个工作流，通过在工作流文件的顶层使用 [`env`](/zh/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#env)。\n* 使用[`jobs..env`](/zh/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenv)查看工作流中的作业内容。\n* 作业中的特定步骤，方法是使用 [`jobs..steps[*].env`](/zh/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsenv)。\n\n```yaml copy\nname: Greeting on variable day\n\non:\n workflow_dispatch\n\nenv:\n DAY_OF_WEEK: Monday\n\njobs:\n greeting_job:\n runs-on: ubuntu-latest\n env:\n Greeting: Hello\n steps:\n - name: \"Say Hello Mona it's Monday\"\n run: echo \"$Greeting $First_Name. Today is $DAY_OF_WEEK!\"\n env:\n First_Name: Mona\n```\n\n可以使用运行器环境变量或上下文访问 `env` 变量值。 上面的示例显示了要在 `echo` 命令中用作运行器环境变量的 3 个自定义变量：`$DAY_OF_WEEK`、`$Greeting` 和 `$First_Name`。 这些变量的值分别在工作流、作业和步骤级别进行设置和范围限定。 这些变量的内插发生在运行器上。\n\n工作流步骤或引用的操作 `run` 中的命令由你在运行器上使用的 shell 处理。 工作流其他部件中的指令由 GitHub Actions 处理，不会发送到运行器。 可以在 `run` 步骤中使用运行器环境变量或上下文，但在未发送到运行器的工作流部件中，必须使用上下文来访问变量值。 有关详细信息，请参阅“[使用上下文访问变量值](#using-contexts-to-access-variable-values)”。\n\n由于运行器环境变量插值是在将工作流作业发送到运行器计算机后完成的，因此必须对运行器上使用的 shell 使用适当的语法。 在此示例中，工作流指定 `ubuntu-latest`。 默认情况下，Linux 运行器使用 bash shell，因此你需要使用语法 `$NAME`。 Windows 运行器默认使用 PowerShell，因此您将使用语法 `$env:NAME`。 有关 shell 的详细信息，请参阅“[GitHub Actions 的工作流语法](/zh/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)”。\n\n## 为多个工作流定义配置变量\n\n可以创建用于多个工作流的配置变量，并且可以在[组织](#creating-configuration-variables-for-an-organization)、[存储库](#creating-configuration-variables-for-a-repository)或[环境](#creating-configuration-variables-for-an-environment)级别定义它们。\n\n例如，可以使用配置变量为传递给组织级别的生成工具的参数设置默认值，但随后允许存储库所有者根据具体情况重写这些参数。\n\n定义配置变量时，它们在 `vars` 上下文中自动可用。 有关详细信息，请参阅“[使用 `vars` 上下文访问配置变量值](#using-the-vars-context-to-access-configuration-variable-values)”。\n\n### 为存储库创建配置变量\n\n要在 GitHub 上为组织存储库创建机密或变量，你必须拥有 `write` 访问权限。对于个人帐户存储库，你必须是存储库协作者。\n\n1. 在 GitHub 上，导航到存储库的主页面。\n2. 在仓库名称下，单击 “Settings”\\*\\*\\*\\*。 如果看不到“设置”选项卡，请选择“”下拉菜单，然后单击“设置”。\n\n ![存储库标头的屏幕截图，其中显示了选项卡。 “设置”选项卡以深橙色边框突出显示。](/assets/images/help/repository/repo-actions-settings.png)\n3. 在边栏的“Security”部分中，选择“ Secrets and variables”，然后单击“Actions”\\*\\*\\*\\*\\*\\*\\*\\*。\n4. 单击“变量”选项卡。\n ![“操作机密和变量”页的屏幕截图。 “变量”选项卡以深橙色标出。](/assets/images/help/repository/actions-variables-tab.png)\n5. 单击“**新建存储库变量**”。\n6. 在“名称”字段中输入变量的名称。\n7. 在“值”字段中输入变量的值。\n8. 单击“**添加变量**”。\n\n### 为环境创建配置变量\n\n要为个人帐户存储库中的环境创建密码或变量，你必须是存储库所有者。 要为组织存储库中的环境创建密码或变量，必须具有 `admin` 访问权限。 有关环境的详细信息，请参阅“[管理部署环境](/zh/enterprise-cloud@latest/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)”。\n\n1. 在 GitHub 上，导航到存储库的主页面。1. 在仓库名称下，单击 “Settings”\\*\\*\\*\\*。 如果看不到“设置”选项卡，请选择“”下拉菜单，然后单击“设置”。\n\n ![存储库标头的屏幕截图，其中显示了选项卡。 “设置”选项卡以深橙色边框突出显示。](/assets/images/help/repository/repo-actions-settings.png)1. 在左侧边栏中，单击“环境”。\n2. 单击你想要添加变量的环境。\n3. 在“**环境变量**”下，单击“**添加变量**”。\n4. 在“名称”字段中输入变量的名称。\n5. 在“值”字段中输入变量的值。\n6. 单击“**添加变量**”。\n\n### 为组织创建配置变量\n\n在组织中创建机密或变量时，可以使用策略来限制存储库的访问。 例如，您可以将访问权限授予所有仓库，也可以限制仅私有仓库或指定的仓库列表拥有访问权限。\n\n组织所有者和拥有“管理组织操作变量”或“管理组织操作机密”权限的用户可以在组织级别创建机密或变量。\n\n有关详细信息，请参阅“[自定义组织角色的权限](/zh/enterprise-cloud@latest/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles)”。\n\n1. 在 GitHub 上，导航到组织的主页面。\n\n2. 在组织名称下，单击 “Settings”\\*\\*\\*\\*。 如果看不到“设置”选项卡，请选择“”下拉菜单，然后单击“设置”\\*\\*\\*\\*\\*\\*\\*\\*。\n\n ![组织配置文件中选项卡的屏幕截图。 “设置”选项卡以深橙色标出。](/assets/images/help/discussions/org-settings-global-nav-update.png)\n\n3. 在边栏的“Security”部分中，选择“ Secrets and variables”，然后单击“Actions”\\*\\*\\*\\*\\*\\*\\*\\*。\n\n4. 单击“变量”选项卡。\n\n ![“Actions 机密和变量”页的屏幕截图。 “变量”选项卡以深橙色标出。](/assets/images/help/repository/actions-variables-tab.png)\n\n > \\[!NOTE]\n > “Actions secrets and variables”页可能不会根据你的权限显示机密和变量的不同选项卡。 组织所有者和拥有“管理组织操作变量”和“管理组织操作机密”权限的用户将看到“变量”\\*\\*\\*\\* 和“机密”\\*\\*\\*\\* 选项卡。 有关详细信息，请参阅“[自定义组织角色的权限](/zh/enterprise-cloud@latest/organizations/managing-peoples-access-to-your-organization-with-roles/permissions-of-custom-organization-roles)”。\n\n5. 单击“**新建组织变量**”。\n\n6. 在“名称”字段中输入变量的名称。\n\n7. 在“值”字段中输入变量的值。\n\n8. 从“**存储库访问**”下拉列表中，选择访问策略。\n\n9. 单击“**添加变量**”。\n\n## 使用上下文访问变量值\n\n上下文是一种访问工作流运行、变量、运行器环境、作业及步骤相关信息的方式。 有关详细信息，请参阅“[上下文参考](/zh/enterprise-cloud@latest/actions/learn-github-actions/contexts)”。 在工作流程中，还有许多其他上下文可用于各种目的。 有关可在工作流中使用特定上下文的位置的详细信息，请参阅“[上下文参考](/zh/enterprise-cloud@latest/actions/learn-github-actions/contexts#context-availability)”。\n\n可以使用 `env` 上下文来访问环境变量值，还可以使用 `vars` 上下文来访问配置变量值。\n\n### 使用 `env` 上下文访问环境变量值\n\n除了运行器环境变量之外，GitHub Actions 还允许使用上下文设置和读取 `env` 键值。 环境变量和上下文旨在用于工作流程中的不同点。\n\n工作流或引用操作中的 `run` 步骤由运行器处理。 因此，可以使用此处的运行器环境变量，对运行器上使用的 shell 使用适当的语法（例如，Linux 运行器上的 bash shell 使用 `$NAME`，Windows 运行器上的 PowerShell 使用 `$env:NAME`）。 在大多数情况下，还可以使用语法为 `${{ CONTEXT.PROPERTY }}` 的上下文来访问相同的值。 区别在于，在作业发送到运行器之前，上下文将被内插并替换为字符串。\n\n但是，在由 GitHub Actions 处理且不会发送到运行器的工作流部件中，无法使用运行器环境变量。 相反，你必须使用上下文。 例如，`if` 条件（用于确定作业或步骤是否发送到运行器）始终由 GitHub Actions 处理。 因此，必须使用条件语句中的 `if` 上下文来访问变量的值。\n\n```yaml copy\nname: Conditional env variable\n\non: workflow_dispatch\n\nenv:\n DAY_OF_WEEK: Monday\n\njobs:\n greeting_job:\n runs-on: ubuntu-latest\n env:\n Greeting: Hello\n steps:\n - name: \"Say Hello Mona it's Monday\"\n if: ${{ env.DAY_OF_WEEK == 'Monday' }}\n run: echo \"$Greeting $First_Name. Today is $DAY_OF_WEEK!\"\n env:\n First_Name: Mona\n```\n\n在前面的示例的此修改中，我们引入了 `if` 条件。 工作流步骤现在仅当 `DAY_OF_WEEK` 设置为“Monday”时才运行。 我们通过使用 `if` 从 `env` 条件语句中访问此值。\n`env` 命令中引用的变量不需要 `run` 上下文。 这些变量被引用为运行器环境变量，并在运行器收到作业后进行内插。 不过，可以选择在将作业发送到运行器之前，通过使用上下文内插这些变量。 输出结果相同。\n\n```yaml\nrun: echo \"${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!\"\n```\n\n> \\[!NOTE]\n> 上下文通常使用美元符号和大括号表示，例如 `${{ context.property }}`。 在 `if` 条件中，`${{` 和 `}}` 是可选的，但如果使用它们，它们必须括住整个比较语句，如上所示。\n\n> \\[!WARNING]\n> 创建工作流和操作时，应始终考虑代码是否可能执行潜在攻击者的不受信任的输入。 某些上下文应被视为不受信任的输入，因为攻击者可能会插入自己的恶意内容。 有关详细信息，请参阅“[安全使用指南](/zh/enterprise-cloud@latest/actions/reference/security/secure-use#understanding-the-risk-of-script-injections)”。\n\n### 使用 `vars` 上下文访问配置变量值\n\n可以使用 `vars` 上下文在整个工作流中访问配置变量。 有关详细信息，请参阅“[上下文参考](/zh/enterprise-cloud@latest/actions/learn-github-actions/contexts#vars-context)”。\n\n如果尚未设置配置变量，则引用该变量的上下文的返回值将为空字符串。\n\n以下示例演示如何在工作流中将配置变量与 `vars` 上下文配合使用。 以下每个配置变量都已在存储库、组织或环境级别上定义。\n\n```yaml copy\non:\n workflow_dispatch:\nenv:\n # Setting an environment variable with the value of a configuration variable\n env_var: ${{ vars.ENV_CONTEXT_VAR }}\n\njobs:\n display-variables:\n name: ${{ vars.JOB_NAME }}\n # You can use configuration variables with the `vars` context for dynamic jobs\n if: ${{ vars.USE_VARIABLES == 'true' }}\n runs-on: ${{ vars.RUNNER }}\n environment: ${{ vars.ENVIRONMENT_STAGE }}\n steps:\n - name: Use variables\n run: |\n echo \"repository variable : $REPOSITORY_VAR\"\n echo \"organization variable : $ORGANIZATION_VAR\"\n echo \"overridden variable : $OVERRIDE_VAR\"\n echo \"variable from shell environment : $env_var\"\n env:\n REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}\n ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}\n OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}\n \n - name: ${{ vars.HELLO_WORLD_STEP }}\n if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}\n uses: actions/hello-world-javascript-action@main\n with:\n who-to-greet: ${{ vars.GREET_NAME }}\n```\n\n## 检测操作系统\n\n通过使用 `RUNNER_OS` 默认环境变量和相应的上下文属性 `${{ runner.os }}`，可以编写可用于不同操作系统的单个工作流文件。 例如，如果将操作系统从 `macos-latest` 更改为 `windows-latest`，以下工作流可以成功运行，而不必更改环境变量的语法，这会根据运行器使用的 shell 而有所不同。\n\n```yaml copy\non: workflow_dispatch\n\njobs:\n if-Windows-else:\n runs-on: macos-latest\n steps:\n - name: condition 1\n if: runner.os == 'Windows'\n run: echo \"The operating system on the runner is $env:RUNNER_OS.\"\n - name: condition 2\n if: runner.os != 'Windows'\n run: echo \"The operating system on the runner is not Windows, it's $RUNNER_OS.\"\n```\n\n在此示例中，两个 `if` 语句会检查 `os` 上下文的 `runner` 属性以确定运行器的操作系统。\n`if` 条件由 GitHub Actions 处理，只有检查结果为 `true` 的步骤才会发送到运行器。 这里其中一个检查将始终为 `true`，而另一个检查为 `false`，因此只有其中一个步骤会发送到运行器。 在作业发送到运行器后，将执行该步骤，并使用适当的语法（在 Windows 上针对 PowerShell 使用 `echo`，在 Linux 和 macOS 上针对 bash 和 sh 使用 `$env:NAME`）对 `$NAME` 命令中的环境变量进行内插。 在此示例中，语句 `runs-on: macos-latest` 表示将运行第二个步骤。\n\n## 在工作流程中的步骤和作业之间传递值\n\n如果在作业的某个步骤中生成值，则可以在同一作业的后续步骤中使用该值，方法是将该值分配给现有或新的环境变量，然后将其写入 `GITHUB_ENV` 环境文件。 环境文件可由操作直接使用，也可以通过使用 `run` 关键字在工作流文件中通过 shell 命令使用。 有关详细信息，请参阅“[GitHub Actions 的工作流命令](/zh/enterprise-cloud@latest/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable)”。\n\n如果要将工作流程中一个作业的某个步骤中的值传递到工作流程中另一作业的某个步骤，可以将该值定义为作业输出。 然后，可以从另一个作业中的步骤引用此作业输出。 有关详细信息，请参阅“[GitHub Actions 的工作流语法](/zh/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idoutputs)”。\n\n## 后续步骤\n\n有关参考信息，请参阅 [变量参考](/zh/enterprise-cloud@latest/actions/reference/variables-reference)。"}