GitLab Pipeline执行报错：已删除的旧Volume配置引发权限问题

可能的原因及对应解决方法 #

1. Runner工作目录残留旧文件/目录 #

GitLab Runner（尤其是使用shell executor或绑定宿主机目录的docker executor）的工作目录可能留存了之前job创建的db_data、sql相关目录。这些目录的权限可能被之前的容器设置为当前Runner用户无法操作的状态，导致后续job即使移除了挂载配置，Docker Compose在初始化或清理环节仍会尝试访问这些残留目录，触发权限错误。

解决步骤：

• 在unit-test-job的脚本开头添加清理命令，删除旧残留目录：

  rm -rf Docker/test/db_data Docker/test/sql
  

• 如果使用docker executor，确保job配置没有挂载宿主机无关目录，或者在job结束后清理容器内的工作目录。

2. Docker Compose缓存了旧服务配置 #

Docker Compose会缓存容器的配置信息，哪怕你修改了docker-compose.yml，如果没有彻底重建容器，仍可能沿用旧的挂载配置。

解决步骤：

• 执行docker-compose up前，先清理旧容器和关联卷：

  docker-compose -f Docker/test/docker-compose.yml down -v --remove-orphans
  

  参数说明：
  • -v：删除容器关联的匿名卷；
  • --remove-orphans：清理当前配置中未定义的服务容器。

3. Git仓库未同步最新的docker-compose.yml #

如果修改后的docker-compose.yml没提交到Git仓库，或者Pipeline运行的分支不是包含最新修改的分支，Runner拉取的仍是旧配置，自然会继续尝试挂载已删除的目录。

解决步骤：

• 确认修改后的docker-compose.yml已提交并推送到对应分支；
• 检查Pipeline触发分支是否正确，确保Runner拉取的是最新代码。

4. GitLab Runner缓存保留了旧文件 #

如果job配置了cache字段，且将Docker/test目录纳入缓存范围，旧的db_data、sql目录会被缓存下来，每次job执行时都会恢复，导致权限问题。

解决步骤：

• 检查.gitlab-ci.yml的cache配置，排除不需要缓存的目录：

  cache:
    paths:
      # 保留需要缓存的路径，同时排除旧目录
      - your-other-cache-paths/
    exclude:
      - Docker/test/db_data/
      - Docker/test/sql/
  

• 手动清理Runner缓存：进入GitLab项目的Settings -> CI/CD -> Pipelines，点击Clear runner cache。

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