如何根据前置阶段失败状态将后续作业设置为手动触发

你可以通过内置作业状态判断+dotenv变量跨作业传递+rules条件触发的组合方式实现需求，全程使用GitLab CI原生能力，不需要依赖第三方工具。

1. 修改Teardown作业配置 #

保留你原有的allow_failure: true配置，新增状态透传逻辑：不管Teardown执行成功还是失败，都把最终执行状态写入变量文件，通过dotenv报告传递给下游作业。
参考配置如下：

teardown:
  stage: Teardown
  allow_failure: true # 原有配置保留
  script:
    # 此处保留你原有的删除K8s已部署应用的全部逻辑，例如kubectl delete相关命令
    - kubectl delete -f ./app-deploy.yaml
  after_script:
    # after_script段无论作业成功失败都会强制执行，适合用来采集作业最终状态
    - |
      if [ "$CI_JOB_STATUS" = "success" ]; then
        echo "TEARDOWN_EXIT_STATUS=success" > job_status.env
      else
        echo "TEARDOWN_EXIT_STATUS=failed" > job_status.env
      fi
  artifacts:
    when: always # 核心配置：无论作业成败都上传状态制品，否则失败场景下下游拿不到变量
    reports:
      dotenv: job_status.env

2. 修改Destroy作业配置 #

移除Destroy作业原来全局配置的自动触发规则，改用rules根据透传的Teardown状态动态决定触发方式：

• Teardown执行成功时，Destroy自动运行
• Teardown执行失败时，Destroy改为手动触发，阻塞流水线等待人工核查后操作
  参考配置如下：

destroy:
  stage: Destroy
  needs: [teardown] # 明确依赖Teardown作业，确保优先拿到透传的状态变量
  script:
    # 此处保留你原有的删除K8s集群、清理关联资源的全部逻辑
    - terraform destroy -auto-approve
  rules:
    # Teardown成功场景：自动执行
    - if: $TEARDOWN_EXIT_STATUS == "success"
      when: on_success
    # Teardown失败场景：手动触发，阻塞流水线等待人工确认
    - if: $TEARDOWN_EXIT_STATUS == "failed"
      when: manual
      allow_failure: false

关键注意事项 #

• 不要在Destroy作业上配置全局的when: always，该配置优先级高于rules，会导致条件触发规则失效
• 如果你的GitLab实例版本低于13.5（不支持dotenv报告），可以把状态写入普通文本制品，在Destroy作业的script开头拉取制品读取状态值做判断即可，逻辑完全一致
• when: manual搭配allow_failure: false时，流水线会停在待确认状态，不会直接标记为成功/失败，符合你核查问题后再执行的需求

内容的提问来源于stack exchange，提问作者Jor-El