如何在GitLab中配置长耗时job不阻塞MR合并的流水线

GitLab 完全可以实现你需要的流水线配置，核心通过CI内置关键字配合基础合并规则即可实现，无需额外插件。

核心配置逻辑 #

你需要先开启项目的「Pipelines must succeed」设置，保证MR合并必须依赖流水线判定为成功，再按如下规则编写.gitlab-ci.yml：

stages:
  - build
  - report

# 构建job，作为MR合并的必要条件
build:
  stage: build
  script:
    - 你的构建执行命令
  only:
    - merge_requests

# 静态分析job，不阻塞合并但必须执行完成
report:
  stage: report
  script:
    - 你的静态代码分析执行命令
    - 结果推送至MR的命令
  only:
    - merge_requests
  needs: ["build"]
  optional: true
  interruptible: false

配置说明 #

• needs: ["build"]：保证report只会在build执行成功后启动，避免构建失败时浪费资源运行耗时较长的静态分析
• optional: true：该job的执行状态不会影响流水线整体的成功/失败判定，只要build执行成功，整个流水线就会被标记为成功，MR即可正常合并，无需等待report执行完成
• interruptible: false：禁止系统或用户在MR合并后取消仍在运行的reportjob，保证该job一定会执行完成并把结果推送至MR
• 默认保留allow_failure: false配置：如果report本身执行出错，会单独标记该job失败，你可以额外配置对应失败告警通知负责人，不会影响已合并的MR。

低版本兼容方案 #

如果你使用的是GitLab 15.3以下的版本（optional关键字从15.3版本开始支持），可以把optional: true替换为allow_failure: true，再进入项目CI/CD设置页面，在「Pipeline success for these jobs」选项中仅勾选build作为必须成功的job，最终效果完全一致。

这个方案可以完美规避你提到的三类问题：

• 全程不需要关闭「Pipelines must succeed」设置，只有build成功时流水线才会判定为成功，不会出现构建失败仍可合并MR的情况
• 不需要手动取消reportjob，也不会出现report被随意取消的情况，保证一定会执行完成
• report在build成功后立刻启动，不需要等待MR合并，执行结果可以正常推送到MR页面通知相关人员，哪怕MR已经合并也可以在MR详情页查看报告。

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