GitHub Actions：复用工作流（uses定义Job）能否使用Workflow级Env上下文？

核心问题解答 #

不能直接在uses块的with参数中引用工作流级别的env上下文。原因是GitHub Actions在解析uses配置时，工作流级别的env还未被初始化，因此会抛出Unrecognized named-value: 'env'错误。

解决方案（满足仅当前工作流生效、无需重复定义） #

方案1：使用工作流级vars替代env #

vars上下文在工作流解析阶段即可被访问，适合在uses中传递变量，且仅对当前工作流生效。

主工作流修改如下：

name: Build and Publish Helm charts
on:
  push:
    branches:
      - "main"
vars:
  FOO: BAR
jobs:
  test:
    uses: '.github/workflows/test.yaml'
    with:
      FOO: ${{ vars.FOO }}

子工作流test.yaml需定义对应的输入参数：

name: Test Workflow
on:
  workflow_call:
    inputs:
      FOO:
        type: string
        required: true
jobs:
  run-test:
    runs-on: ubuntu-latest
    steps:
      - name: Print FOO
        run: echo "FOO is ${{ inputs.FOO }}"

方案2：通过前置Job传递env变量（适合必须使用env的场景） #

如果依赖工作流级env，可以先通过一个前置Job将env变量导出为输出，再通过needs传递给uses的Job：

主工作流修改如下：

name: Build and Publish Helm charts
on:
  push:
    branches:
      - "main"
env:
  FOO: BAR
jobs:
  export-env:
    runs-on: ubuntu-latest
    outputs:
      foo: ${{ env.FOO }}
    steps:
      - name: Export env to output
        run: echo "foo=${{ env.FOO }}" >> $GITHUB_OUTPUT
  test:
    needs: export-env
    uses: '.github/workflows/test.yaml'
    with:
      FOO: ${{ needs.export-env.outputs.foo }}

子工作流的输入定义与方案1一致。

方案对比 #

• 方案1更简洁，vars专为工作流级静态变量设计，无需额外Job即可直接在uses中引用，完全满足“仅当前工作流生效、一处定义共享”的需求。
• 方案2适用于必须依赖env的场景（比如env值来自其他动态生成逻辑），但需要额外的前置Job处理变量传递。

内容的提问来源于stack exchange，提问作者Julien Kieffer