为何to-be-continuous/terraform的tf-plan-production仅在合并请求流水线运行

to-be-continuous的Terraform模板这个规则设计是出于风险管控和资源效率两个层面的考量：

• 核心风险前置校验：合并请求阶段的最高优先级评审目标是确认代码合并后对生产环境的实际影响，tf-plan-production作业会直接基于生产环境的状态、变量生成执行计划，评审人可以直接看到合并会新增、修改、删除哪些生产资源，避免问题代码合入后引发生产故障，这是MR阶段唯一必须跑的作业。
• 避免重复执行浪费资源：其余作业的定位都是分支级别的检查，不需要在MR流水线重复运行：
  • tf-tflint、tf-checkov这类静态检查作业，执行不依赖环境上下文，代码推送到分支后就会在独立分支流水线中运行，检查结果会自动同步到关联的MR页面，完全不影响评审参考
  • tf-plan-review这类作业是针对临时review环境生成执行计划，对应分支维度的临时环境生命周期，本身就不需要在MR流水线中执行

你观察到的两条并行流水线是模板的预期设计，不是配置异常：

• 一条是分支流水线：代码推送到功能分支时触发，运行所有配置了如下规则的作业：

  # exclude merge requests
  - if: $CI_MERGE_REQUEST_ID
    when: never
  

  负责静态校验、临时环境计划生成
• 一条是MR流水线：分支关联打开的合并请求时触发，仅运行tf-plan-production作业（该作业配置了- if: $CI_MERGE_REQUEST_ID的触发规则），专门提供生产环境变更预览供评审使用

两条流水线职责完全拆分，没有冗余执行，你不需要修改默认规则即可正常使用。如果确实有需要把部分作业加入MR流水线的需求，可以在项目的.gitlab-ci.yml中单独重载对应作业的rules规则，不会破坏模板的原有设计逻辑。

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