GitLab CI中$CI_JOB_ID等ID类变量无法作为作业标签解析

你的判断是准确的：tags 配置属于GitLab CI的预调度解析项，这个阶段的核心逻辑是匹配对应标签的Runner，还没完成作业的实例化流程，$CI_JOB_ID、$CI_PIPELINE_ID这类全局唯一ID是作业正式分配到Runner、完成实例化后才会生成赋值，因此预调度阶段解析时会直接将这类未赋值的变量识别为普通字符串，不会做变量替换。
你提到的$CI_JOB_NAME、$CI_PIPELINE_IID能正常解析，是因为这两个变量在流水线配置加载、预调度阶段就已经确定值，但二者都无法单独作为单个作业的唯一标识：同一流水线内的重名作业、作业重试场景下$CI_JOB_NAME值完全一致，$CI_PIPELINE_IID是项目维度的流水线自增序号，同一条流水线内的所有作业共享该值。

预调度阶段生成作业唯一标签的可行方案 #

• 组合预调度阶段可解析的内置变量生成唯一值
  把预调度阶段已完成赋值的内置变量拼接，即可生成单作业维度的唯一标识，直接写入tags配置即可生效，参考配置：

  some-cool-job:
    tags:
      - "job_${CI_PROJECT_ID}_${CI_PIPELINE_IID}_${CI_JOB_STAGE}_${CI_JOB_NAME}"
  

  如果使用了parallel并行矩阵策略，同个阶段下会存在多个同名作业，额外拼接$CI_NODE_INDEX变量即可，该变量是并行作业的分片索引，预调度阶段已完成赋值，组合后不会出现标签重复的问题。
• 触发流水线时传入自定义唯一标识
  如果是API触发、Webhook触发、手动触发流水线的场景，可以在触发请求中提前传入预生成的唯一值（比如UUID）作为自定义流水线变量，tags配置直接引用该自定义变量即可。用户传入的流水线变量在配置加载的最早期就会完成注入，不存在解析失败的问题。

注意：不要尝试在作业的script执行阶段通过命令修改tags配置，tags是Runner调度的匹配规则，当作业进入script执行阶段时，已经完成了Runner匹配和调度流程，此时修改tags不会产生任何实际效果。

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