GitHub Actions中超25GB Docker服务容器无法加载的解决办法咨询

针对你遇到的大容器（21-25GB）拉取时存储空间不足的问题，核心矛盾是GitHub Actions的services会在所有steps之前启动，导致空间清理操作晚于镜像拉取。这里提供一个直接有效的解决思路：放弃services字段，在steps中手动控制镜像拉取和容器启动的顺序，确保先完成空间释放再处理大镜像。

具体工作流配置示例 #

name: Address Testing
on: workflow_dispatch
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: 最大化构建空间
        uses: easimon/maximize-build-space@master
        with:
          root-reserve-mb: 512
          swap-size-mb: 1024
          remove-dotnet: 'true'
          remove-android: 'true'
          # 可根据需要添加更多清理项，进一步释放空间
          remove-node: 'true'
          remove-python: 'true'

      - name: 拉取gnafloader镜像
        run: docker pull minus34/gnafloader:latest

      - name: 启动gnafloader容器
        run: |
          docker run -d \
            --name gnafloader-db \
            -p 5432:5432 \ # 根据容器实际暴露的端口调整，假设是PostgreSQL
            minus34/gnafloader:latest

      - name: 等待容器就绪
        run: |
          # 以PostgreSQL为例，等待数据库服务启动完成
          until docker exec gnafloader-db pg_isready -U postgres; do
            sleep 5
          done

      # 后续测试步骤示例
      - name: 执行地址测试
        run: |
          # 连接容器内的数据库执行测试命令
          psql -h localhost -U postgres -d gnaf -c "SELECT COUNT(*) FROM address;"

方案说明 #

1. 顺序可控：所有操作都在steps中按顺序执行，先完成空间清理，再拉取镜像、启动容器，从根源避免空间不足的问题。
2. 灵活配置：可以根据容器的实际需求调整docker run的参数（如端口映射、环境变量、挂载卷等），完全适配你的测试场景。
3. 就绪检查：添加等待容器就绪的步骤，避免后续测试连接未启动完成的服务导致失败。

如果需要进一步释放空间，可以参考easimon/maximize-build-space的功能，添加更多清理选项，比如移除预装的Java、Ruby等环境，尽可能腾出存储空间容纳大镜像。

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