基于alpine构建的镜像在GitLab流水线跑Cypress退出码137问题咨询

退出码137本质是进程收到SIGKILL信号被强制终止，除了内存不足触发系统OOM杀手之外，还有以下常见诱因：

• GitLab Job超时限制：如果项目CI/CD配置中对应Job的timeout参数设置短于测试实际需要的运行时长，GitLab会主动终止任务返回137，和内存无关。你可以在CI脚本中添加dmesg | grep -i oom命令，确认是否存在OOM杀手的 kill 日志，先排除超时问题。
• 进程僵死阻塞：前后端启动逻辑存在依赖缺失，比如后端启动需要连接的数据库、缓存等中间件在CI环境中不可用，又没有配置启动失败退出逻辑，会导致front:wait/back:wait健康检查脚本无限重试，后台运行的前后端进程持续占用资源累加直到触发OOM。
• Concurrently进程管理异常：concurrently默认不会在单个子进程出错时主动终止所有关联进程，如果其中某一个子进程（比如Cypress）崩溃后没有发出退出信号，三个进程会持续驻留占用内存，直到被Runner的资源限制杀掉。
• GitLab Runner默认资源限制：就算宿主机内存充足，未配置Runner的memory_limit/memory_swap参数的情况下，Runner会给每个Job分配默认的内存配额，只要总资源占用超阈值就会直接发送SIGKILL，和镜像本身无关。
• Alpine镜像兼容问题：alpine使用musl libc而非常规的glibc，Cypress无头模式依赖的部分系统库在musl环境下运行存在已知的内存泄漏问题，长时间运行会持续占用内存直到触发OOM。

扩容内存相关操作 #

• 私有GitLab Runner可修改config.toml配置，在对应Executor的配置段增加memory_limit = "4g" memory_swap = "8g"，给单Job分配足够的内存配额；如果使用GitLab官方共享Runner，可升级付费的更大资源规格的Runner。
• 调整Docker daemon的内存限制：如果Runner用Docker Executor，宿主机Docker daemon默认内存上限设置过低也会限制容器内存，Windows/Mac桌面版Docker可直接在设置里调整内存上限到4G以上，Linux系统可修改/etc/docker/daemon.json的相关内存参数。

降低内存消耗操作 #

• 优化启动流程，不要用concurrently同时跑全部进程：改成分步启动，先启动后端，健康检查通过后再启动前端，前端健康检查通过后再运行Cypress，测试完成后主动杀死前后端进程，避免三个高消耗进程同时长时间驻留。示例调整后的脚本：

"e2e:run": "yarn back & yarn back:wait && yarn front & yarn front:wait && yarn cypress:run && pkill -f 'yarn front' && pkill -f 'yarn back'"

• 给Node.js进程限制内存上限：启动前后端时加上Node内存限制参数，避免单进程无限制占用内存，比如"front": "node --max-old-space-size=1024 node_modules/vite/bin/vite dev"，后端同理设置对应内存上限。
• 调整Cypress运行参数：无头模式下关闭不必要的插件、关闭不需要的视频录制/截图功能，增加--memory 2048参数限制Cypress自身的内存占用，测试用例可分批运行，避免一次性加载太多用例导致内存飙升。
• 替换基础镜像：如果确认是alpine的兼容问题，可换成基于Debian的slim镜像，虽然镜像体积更大，但Cypress运行稳定性更高，不存在musl导致的内存泄漏问题。
• 启用Swap交换分区：如果宿主机内存确实不足，可临时开启Swap分区，降低OOM概率，虽然会降低运行速度，但可避免直接报错退出。

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