GitLab CI：在exists规则中使用环境变量失效问题求助

你猜的完全没错！GitLab CI 在处理 rules:exists 规则时，确实不会展开环境变量——这是因为这个规则的评估时机非常早：它是在流水线创建阶段（GitLab 服务器端）就执行的，此时环境变量（包括你通过计划传入的 ${ENV}）还没有被注入到评估上下文中，所以带变量的路径会被当成字面量（比如 foo/bla/${ENV}/foo.json）去检查文件是否存在，自然匹配不到实际的文件。

可行的解决方案：用 rules:if 结合文件检查命令 #

既然 exists 不支持变量，我们可以换用 rules:if，在条件里直接用 shell 命令检查文件是否存在——这个阶段环境变量已经可以被正常解析了。

Bash 环境（大多数 Linux/macOS Runner）的配置示例：

your_target_job:
  script:
    - # 这里写你的作业执行命令
  rules:
    - if: '$ENV != "" && [ -f "$CI_PROJECT_DIR/foo/bla/${ENV}/foo.json" ]'
      when: always

Windows PowerShell 环境的配置示例：

如果你的 Runner 用的是 PowerShell，把检查命令换成 PowerShell 的语法：

your_target_job:
  script:
    - # 你的作业命令
  rules:
    - if: '$ENV != "" && Test-Path "$CI_PROJECT_DIR/foo/bla/${ENV}/foo.json"'
      when: always

关键细节说明 #

• 先验证变量存在：$ENV != "" 的判断是为了避免变量为空时，路径变成 foo/bla//foo.json 这种无效路径导致误判。
• 使用 CI_PROJECT_DIR：这个预定义变量指向 Runner 上的项目仓库根目录，确保文件路径是绝对路径，避免相对路径的歧义。
• 时机差异：rules:if 的条件是在 Runner 执行作业前评估的，此时环境变量已经被正确注入，所以 ${ENV} 会被替换成实际的变量值。

为什么 rules:exists 不行？ #

再补充解释下背后的逻辑：rules:exists 是 GitLab 服务器直接和仓库交互检查文件存在性的，不需要 Runner 参与。这个过程发生在流水线被创建的早期，此时所有自定义变量（包括计划变量）还没有被加载到评估环境中，所以变量无法被解析——只有静态的、硬编码的路径才能被正确识别。

内容的提问来源于stack exchange，提问作者Gilbert Williams