如何让GitLab中手动触发的deploy任务失败时自动执行回滚脚本

核心错误点 #

• 缺失全局stages声明：你新增的cloudformation_stack_rollback阶段没有加入全局阶段顺序配置，GitLab CI无法识别阶段执行优先级，直接触发linter错误。必须将该阶段放在deploy阶段之后，才能确保在deploy作业执行后再判断是否触发回滚。
• CI_JOB_MANUAL变量使用逻辑错误：该变量是标记当前作业自身是否为手动触发，你的回滚作业本身不是手动触发类型，因此这个if判断永远不生效。你需要的是匹配deploy作业所在的分支/环境条件，而非判断当前作业的触发类型。
• CI_ENVIRONMENT_NAME变量无效：回滚作业没有绑定环境配置，也没有继承deploy作业的相关属性，运行时$CI_ENVIRONMENT_NAME为空值，最终生成的STACK_NAME不符合预期，就算作业触发也会执行失败。
• 缺少分支匹配规则：当前回滚作业没有限制分支范围，会在所有分支的deploy作业失败时触发，不符合你仅在qas分支部署的配置逻辑。

修复后配置示例 #

# 首先声明全局阶段，按执行顺序排列，新增的回滚阶段放在最后
stages:
  - build
  - test
  - code_analysis
  - compliance
  - deploy
  - cloudformation_stack_rollback

include:
  - remote: 'https://my-gitlab-server.com/ci-templates/-/raw/master/serverless-template.yml'

deploy-qas:
  extends: .deploy
  variables:
    # 原有变量保持不变
    PARAMETER_OVERRIDES: "..."
  environment: qas
  only:
    - qas
  tags:
    - serverless

cleanup-cloudformation-stack-failure:
  # 继承.deploy模板的凭证、tags等配置，避免aws cli权限不足的问题
  extends: .deploy
  variables:
    STACK_NAME: $CI_PROJECT_NAME-$CI_ENVIRONMENT_NAME
  stage: cloudformation_stack_rollback
  environment: qas
  rules:
    # 匹配qas分支，和deploy-qas的触发分支保持一致
    - if: '$CI_COMMIT_BRANCH == "qas"'
      # 只要同流水线中前面的作业（这里就是deploy-qas）失败就触发
      when: on_failure
  script:
    - aws cloudformation continue-update-rollback --stack-name ${STACK_NAME} --resources-to-skip ${STACK_NAME}

多环境适配说明 #

如果后续需要适配prod等其他环境，可以把回滚作业封装为隐藏模板，不同环境的回滚作业继承模板即可，不用重复写配置。

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