GitLab pipeline测试任务耗时过长、挂起超时被取消如何排查

• 先核对job运行的runner属性差异
  拉取异常时段、正常时段的job全量日志，翻到日志最开头确认执行任务的runner ID、执行器类型、基础镜像信息。GitLab平台提供的公共共享runner普遍存在资源超卖问题，免费额度的runner经常会被调度到CPU抢占率高、磁盘IO打满的底层故障节点，直接导致任务跑速骤降甚至完全挂死。如果你的CI配置里基础镜像用了latest标签，还要确认上游镜像是否在异常时段发了新版本，存在兼容问题、镜像拉取卡层校验也会导致无征兆挂死。之前异常自行恢复的情况，基本就是故障runner节点被运维下线、下次任务调度到了正常节点，和代码变更无关。
• 开启调试日志定位卡死前的最后执行步骤
  在项目CI变量里设置CI_DEBUG_TRACE = true重跑异常任务，看日志最终停在哪一步。绝大多数无报错挂死都是没有配置超时时间的网络请求导致的：比如测试逻辑依赖的外部数据库、缓存、第三方Mock服务，对平台runner的出口IP段做了限流/拉黑，TCP握手阶段无回包也无拒绝响应，进程会一直阻塞等待；另外依赖源网络不通、限流导致包下载卡住，也是高频诱因——你本地mac、本地自托管docker runner走的是本地网络，平台runner走的是GitLab机房网络，网络策略差异会直接导致这类问题偶发。
• 核对资源配额差异
  你本地docker部署的runner默认没有硬CPU、内存限制，GitLab公共runner给普通任务的配额通常是2核4G甚至更低，如果测试用例启动了大内存服务、开了高并行度，内存触顶触发OOM时，部分语言的进程不会直接抛出OOM报错，会进入不可中断睡眠状态，外部表现就是完全无日志输出、一直挂到超时。如果能拿到对应runner的监控，重点看异常时段的内存、CPU、IO使用率，以及有没有OOM kill记录。
• 针对性做临时规避
  排查阶段可以先给测试任务加retry: 1的重试规则，这类调度到故障节点、网络临时波动的问题，重试时调度到正常节点即可恢复。如果要彻底规避平台runner的波动影响，可以直接给测试任务指定你本地部署的自托管runner标签，绕开公共资源池的不稳定问题。另外可以在测试执行逻辑里加定时进度打印，比如每30秒输出一次当前测试执行进度、内存占用，避免长测试无日志输出被GitLab判定为挂起。

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