GitLab CI/CD中Docker Compose容器跨Job丢失，如何解决测试问题？

GitLab CI的每个Job都运行在独立的执行环境中，docker-build阶段启动的容器仅存在于该Job对应的Runner容器里。当进入run-tests阶段时，会启动一个全新的Runner环境，自然找不到之前创建的容器——这就是容器消失的核心原因。

方案1：合并构建与测试到同一个Job（最简单直接） #

把构建和测试逻辑放在同一个Job中，避免环境切换导致的容器丢失：

variables:
  DOCKER_DRIVER: overlay2

image:
  name: docker:26.1.3

services:
  - docker:26.1.3-dind

before_script:
  - docker version
  - docker compose version

build-and-test:
  stage: test
  script:
    - docker compose down
    - docker compose up -d --build
    - docker compose exec app php vendor/bin/codecept run
    - docker compose down # 可选，测试完成后清理资源

方案2：通过CI工件传递镜像（适合必须分阶段的场景） #

如果需要严格区分构建和测试阶段，可以在docker-build阶段把构建好的镜像导出为文件，作为CI工件传递到run-tests阶段，再重新加载启动容器：

variables:
  DOCKER_DRIVER: overlay2
  IMAGE_TAR: app-image.tar
  # 替换成你的docker-compose.yml中app服务对应的镜像名
  APP_IMAGE_NAME: your-app-image:latest

image:
  name: docker:26.1.3

services:
  - docker:26.1.3-dind

before_script:
  - docker version
  - docker compose version

docker-build:
  stage: build
  script:
    - docker compose build app
    - docker save -o $IMAGE_TAR $APP_IMAGE_NAME
  artifacts:
    paths:
      - $IMAGE_TAR
    expire_in: 1 hour # 按需设置工件过期时间

run-tests:
  stage: test
  dependencies:
    - docker-build # 关联构建阶段，获取工件
  script:
    - docker load -i $IMAGE_TAR
    - docker compose up -d app
    - docker compose exec app php vendor/bin/codecept run
    - docker compose down

方案3：使用专属Runner的共享卷（不推荐） #

如果使用自己管理的专属Runner，可以配置Runner的共享卷，让多个Job共享Docker的存储目录。但这种方式会破坏Job的环境隔离性，容易出现资源冲突，仅适合单项目、低并发的场景，不推荐在公共Runner中使用。

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