GitHub Actions运行Django测试报退出码137如何排查修复

退出码137本质是进程收到SIGKILL信号被强制终止，在CI场景下90%以上的诱因是进程内存占用超出Runner限制，被系统OOM Killer杀掉。针对贴出的Django+Docker Compose工作流配置，按以下步骤排查修复即可：

核心诱因 #

• GitHub Actions 官方ubuntu-latest Runner默认可用内存约7G，除去系统本身、Docker daemon占用，实际能分配给业务容器的内存不足5G。当前配置没有给容器加内存限制，PostgreSQL、Django应用启动后本身就占用近3G内存，跑测试时Django会初始化测试数据库、加载全量应用上下文，内存峰值很容易触顶被杀。
• 配置中docker-compose up -d --build执行完立刻触发测试命令，此时数据库、Django服务实际还没完成初始化，异常连接重试也会额外占用内存。
• Django测试默认会根据CPU核心数开多进程并行执行，多进程同时加载测试用例很容易把内存打满。

修复步骤 #

1. 给Docker Compose服务加资源限制
   编辑你的docker-compose.yml，给应用、数据库服务加上明确的内存上限，同时调大PostgreSQL默认过小的共享内存配置：

services:
  my_app:
    # 保留你原有所有my_app服务的配置
    deploy:
      resources:
        limits:
          memory: 2G
  postgres: # 和你自己配置里的数据库服务名对齐
    # 保留你原有所有数据库服务的配置
    deploy:
      resources:
        limits:
          memory: 1G
    shm_size: '256m'

2. 优化测试执行命令，降低内存峰值
   把工作流中Run tests步骤的命令替换为单进程执行，关闭不必要的并行加载：

- name: Run tests
  run: docker exec my_app python manage.py test --parallel 1 --noinput

如果后续测试速度太慢，可以逐步把--parallel后面的数值往上调，每次调整后观察内存占用，不要一开始就开高并行。

3. 新增服务就绪等待步骤
   在启动容器和执行测试两个步骤之间插入等待逻辑，等服务完全启动后再跑测试，避免无效的资源消耗：

- name: Wait for services ready
  run: |
    # 循环等待PostgreSQL就绪
    while ! docker exec $(docker ps -qf "name=postgres") pg_isready -U ${{ secrets.POSTGRES_USER }} -d ${{ secrets.POSTGRES_DATABASE }}; do
      sleep 2
    done
    # 额外等待Django完成初始化
    sleep 5

注意把命令里name=postgres的过滤器值换成你自己数据库容器的实际名称。

4. 可选优化：释放Runner冗余占用的内存
   如果做完以上调整还是报137，可以在Checkout步骤之后加一步清理Runner上预装的无用软件，能额外释放2-3G可用内存：

- name: Free up runner memory
  run: |
    sudo swapoff -a
    sudo rm -f /swapfile
    sudo apt clean
    docker system prune -af

排查辅助 #

如果调整后依然报错，可以在测试步骤后面加一个失败触发的日志采集步骤，直接确认是不是OOM导致的问题：

- name: Collect debug logs on failure
  if: failure()
  run: |
    dmesg | grep -i -A 10 oom
    docker stats --no-stream

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