为何他人在我执行build与apply plan期间运行plan会导致GitLab流水线失败？

核心原因 #

你遇到的依赖锁文件不一致问题，本质是Terraform执行计划（plan.tfplan）与当前环境的依赖状态不匹配，具体源于两个关键点：

• 执行计划的快照特性：terraform plan -out=$PLAN生成的plan.tfplan是包含当时所有状态的快照，包括terraform.lock.hcl依赖锁文件内容、远程Terraform状态、代码与provider版本信息。
• 他人操作的影响：在你生成旧plan后，其他人执行的build并apply操作会更新远程Terraform状态；如果对方的代码更新了provider依赖（比如修改required_providers或执行terraform init -upgrade更新锁文件），仓库里的terraform.lock.hcl会被修改，导致旧plan快照里的锁文件与当前环境的锁文件哈希值不匹配，触发Terraform一致性校验失败。

从你的CI配置看潜在问题 #

你的CI配置里有几个细节放大了这个问题：

• before_script固定执行terraform init -upgrade，每次流水线都会尝试升级provider版本，导致不同时间点的build生成的plan依赖版本可能不一致。
• cache仅缓存.terraform目录，未缓存terraform.lock.hcl，不同流水线的锁文件可能因init -upgrade产生差异。
• Manual Apply阶段直接复用几天前的plan，未校验当前环境与plan的一致性。

解决方案 #

1. 禁止复用过期执行计划
   Terraform执行计划设计为短期有效（通常几小时内），不要复用几天前的plan。需重新触发build阶段生成新的plan后再执行apply。

2. 固定依赖版本并缓存锁文件

• 在Terraform配置里明确指定provider的固定版本，避免自动升级：

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.10.0" # 或使用范围约束如"~> 5.0"
    }
  }
  

• 在CI的cache中添加terraform.lock.hcl，保证所有流水线使用相同锁文件：

  cache:
    paths:
      - .terraform
      - terraform.lock.hcl
  

• 将terraform init -upgrade改为普通的terraform init，仅在主动需要升级依赖时使用-upgrade参数。

3. 在apply前添加一致性校验
   在Manual Apply的脚本中先刷新状态并校验匹配性：

.apply-template:
  script:
    - terraform plan -refresh-only -no-color # 刷新状态，检查与plan是否匹配
    - terraform apply -input=false $PLAN

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