流水线变量分层是什么
流水线变量来自多处：平台级的项目/组/实例变量、作业内 variables、触发时注入、父子管道传递。同名变量按平台定义的优先级覆盖生效，合并规则必须在团队内写清楚，否则「为什么生效的不是我以为的值」会反复出现。调试第一步永远是确认变量的作用域与来源，而不是先改值。
基本信息
| 来源 | 项目/组/实例变量、作业级 variables、触发时覆盖、父管道传递 |
|---|---|
| 优先级 | 以 GitLab《CI/CD variable precedence》与 GitHub 环境作用域定义为准 |
| 实践 | 只在有必要处覆盖；敏感变量走受保护与掩码机制 |
| 命名 | 加前缀区分用途（DEPLOY_、SCAN_），降低撞名概率 |
| 调试 | 先确认变量来自哪个作用域，再排查覆盖顺序 |
典型使用场景
- 多环境部署：TARGET_ENV 由触发或环境定义，管道复用同一套脚本
- 父子管道：父管道把版本号传给子管道，避免各自解析
- 覆盖率阈值：按分支覆写阈值，主干更严
- 敏感参数：密钥走受保护变量，只在受保护分支可见
- 排查行为差异：同一管道在不同环境取值不同，逐层定位来源
- 秘密轮换：变量值更新走配置管理，改完跑一次验证管道
- 文档化：把覆盖顺序整理成一页贴进仓库说明
GitLab 触发时覆盖
GitLab 触发时覆盖
deploy:
variables:
TARGET_ENV: staging
script: ./ci/deploy.sh来源与覆盖
| 来源 | 作用范围 | 覆盖关系 |
|---|---|---|
| 实例/组变量 | 全部项目 | 层级最低 |
| 项目变量 | 单项目 | 可被作业覆盖 |
| 作业 variables | 单作业 | 就近生效 |
| 触发时注入 | 本次管道 | 可覆盖上游同值 |
调试时先打印变量来源与作用域，再排查「为什么生效的不是我以为的值」。
命名即文档：前缀化命名让来源一目了然，评审时也容易发现冲突。
同值不同源是事故温床：部署前打印最终生效值（注意掩码），比事后排查便宜。