GitLab CI如何在after_script阶段强制触发作业失败

GitLab CI 对after_script段的默认设计逻辑是：该段仅用于执行必须落地的清理类操作，段内所有命令的退出码都不会影响作业的最终判定状态，无论段内返回非0退出码、还是显式执行exit 1，作业最终状态都只会由script主执行段的结果决定，这就是示例中job2不符合预期执行成功的核心原因。

方案1：用shell trap替代after_script承载需判定成败的收尾逻辑（无API依赖，推荐） #

after_script的核心特性是无论script段执行成功、失败还是被取消，都会保证执行。这个效果完全可以通过shell内置的trap命令实现，同时收尾逻辑的退出码可以正常传递，直接决定作业最终状态。
改造后的配置示例：

variables:
  var1: "bob"
  var2: "bib"

job_fixed:
  script:
    # 绑定EXIT信号，保证无论后续主逻辑是否报错，收尾逻辑都会执行
    - |
      function cleanup {
        # 此处放原本要写在after_script里的逻辑
        [[ ${var1} == ${var2} ]]
      }
      trap cleanup EXIT
    # 原有主业务逻辑
    - echo "hello"

小提示：如果收尾逻辑包含多条命令，需要任意命令失败就直接判定作业失败，可以在cleanup函数开头加上set -e，避免错误被吞。
这个配置下，主逻辑执行完成后会自动触发cleanup函数执行，当[[ ${var1} == ${var2} ]]判断失败返回非0时，整个作业会直接标记为失败，和预期一致。如果主逻辑中途报错退出，也会先触发cleanup执行，完全覆盖after_script的常规使用场景。

方案2：在after_script中捕获错误，调用GitLab API主动标记作业失败 #

如果场景必须把逻辑放在after_script段（比如需要用到after_script上下文特有的CI_JOB_STATUS等内置变量），可以在段内捕获命令的退出码，当检测到错误时，调用GitLab作业API主动把当前作业状态更新为失败。
前置要求：

• 在项目CI/CD变量中配置一个拥有api权限的访问令牌，比如命名为GITLAB_API_TOKEN，禁止将令牌明文写在CI配置文件中
• 调用API用到的CI_API_V4_URL、CI_PROJECT_ID、CI_JOB_ID均为GitLab CI自动注入的内置变量，无需手动配置

配置示例：

variables:
  var1: "bob"
  var2: "bib"

job_fixed:
  script:
    - echo "hello"
  after_script:
    - |
      # 执行目标校验逻辑，捕获退出码
      [[ ${var1} == ${var2} ]]
      exit_code=$?
      if [ $exit_code -ne 0 ]; then
        echo "after_script 执行出错，主动标记作业为失败状态"
        curl --request PUT \
          --header "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \
          "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/jobs/${CI_JOB_ID}" \
          --form "state=failed"
        exit 1
      fi

注意：该方案需要保证CI Runner可以正常访问GitLab实例的API地址，否则状态更新调用会失败。

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