GitLab Runner Docker-in-Docker环境下docker build无法识别Dockerfile

可能的原因 #

1. 工作目录/上下文路径不匹配：GitLab Runner的Docker Executor会将代码克隆到容器内默认路径（/builds/${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAME}），如果docker-compose.yml的build字段未明确指定context，或执行docker-compose时的工作目录不是项目根目录，就会导致Docker找不到Dockerfile。旧版本Runner的工作目录逻辑可能不同，因此能正常运行。
2. 大小写敏感问题：本地系统（如Windows/macOS）文件名大小写不敏感，但Runner使用的Linux容器严格区分大小写。如果仓库中Dockerfile的实际文件名是小写dockerfile或其他变体，本地能识别但Runner容器内会找不到。
3. GitLab Runner 16.x 行为变化：新版本Runner在代码克隆路径、工作目录配置或Docker Executor默认行为上有调整，与旧版本不兼容。
4. Docker-Compose 版本差异：本地使用的Docker-Compose版本与Runner容器内的版本不一致，导致对build字段的解析逻辑不同。

解决方法 #

1. 修正 docker-compose.yml 的 Build 配置 #

确保build字段明确指定context为项目根目录，无需额外的-f Dockerfile参数（默认会在context目录下查找Dockerfile）：

services:
  your-service-name:
    build:
      context: .  # 明确指定上下文为当前目录
      dockerfile: Dockerfile  # 文件名是默认值时可省略
    # 其他服务配置...

2. 验证 Runner 容器内的文件结构 #

在.gitlab-ci.yml的before_script中添加检查命令，确认Dockerfile是否存在：

before_script:
  - pwd  # 打印当前工作目录
  - ls -la  # 列出当前目录下所有文件
  - docker-compose --version  # 检查Docker-Compose版本

通过输出可确认：代码是否正确克隆、Dockerfile是否存在、当前工作目录是否为项目根目录。

3. 检查 Dockerfile 文件名大小写 #

确保仓库中的Dockerfile文件名是大写开头的Dockerfile，而非dockerfile或其他变体。这是本地正常但Runner报错的常见原因。

4. 调整 Runner 配置或 Git 克隆策略 #

• 若Runner的config.toml中自定义了working_dir，确认其指向正确的项目克隆路径（默认是/builds/${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAME}）。
• 在.gitlab-ci.yml中强制使用完整克隆策略，避免增量克隆导致文件缺失：

variables:
  GIT_STRATEGY: clone

5. 统一 Docker-Compose 版本 #

如果本地与Runner内的Docker-Compose版本差异较大，可在Runner容器内安装与本地一致的版本：

before_script:
  - apk add --no-cache py3-pip
  - pip install docker-compose==<你的本地版本号>  # 例如 2.20.2

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