购买GitLab额外存储后流水线仍提示设备空间不足求助

一、购买的10GB额外存储用途说明 #

你购买的额外存储并非用于流水线Runner节点的运行时磁盘空间，而是用于GitLab项目的以下存储场景：

• 仓库代码存储（超出免费额度的部分）
• Git LFS文件存储
• 制品库（如容器镜像、NuGet包等）
• 项目Wiki、Issue附件等

Runner节点的磁盘是GitLab共享Runner的固定资源，每个Job分配的磁盘空间独立，和你购买的项目存储额度无关，因此df -h显示的空间不会因购买额外存储而变化。

二、解决「No space left on device」错误的可行方案 #

1. 优化tarball打包逻辑 #

• 打包前清理冗余文件：在打包步骤前执行清理命令，删除不需要的大文件或缓存目录：

  rm -rf node_modules .git logs tmp/*
  

• 精准控制打包内容：避免打包整个目录，只包含必要文件，用tar命令的--exclude参数排除无关文件：

  tar --exclude='node_modules' --exclude='.git' --exclude='logs' -czf /builds/myNamespace/sps/output/.temp/project.tar.gz ./src ./package.json
  

2. 调整CI流水线的缓存与制品配置 #

• 限制缓存范围：只缓存必要的依赖，避免缓存过大，同时设置缓存过期策略：

  cache:
    paths:
      - node_modules/
    policy: pull
    expire_in: 1 week
  

• 排除不必要的制品：如果有上传制品的步骤，用artifacts:exclude排除大文件：

  artifacts:
    paths:
      - output/
    exclude:
      - output/.temp/
  

3. 切换Runner类型（终极方案） #

GitLab共享Runner的磁盘空间无法扩容，若你的流水线需要持续生成大文件，建议使用自托管Runner：

• 自行部署Runner服务器，配置更大的磁盘空间
• 自定义Runner镜像，预装Docker等必要工具，解决docker prune无法使用的问题

4. 替代打包逻辑（若构建Docker镜像） #

如果流水线核心是构建并推送Docker镜像，可直接使用支持Docker的Runner镜像，跳过tarball打包步骤：

image: docker:latest
services:
  - docker:dind

build:
  script:
    - docker build -t my-image:latest .
    - docker login -u $DOCKER_HUB_USER -p $DOCKER_HUB_PASS
    - docker push my-image:latest

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