核心是环境一致、步骤可控、失败可查：用docker-compose.test.yml定义隔离可复现的测试依赖，CI中通过docker-compose up启动、run执行测试、down清理，并上传测试报告与日志。
用 Docker Compose 配合 GitLab CI 搭建全自动持续集成测试，核心是让每次代码提交后，自动拉起一套隔离、可复现的测试环境，运行单元测试、集成测试等，并反馈结果。关键不在“全”，而在“稳”和“快”——环境一致、步骤可控、失败可查。
准备可复用的测试环境定义
把测试依赖（如数据库、缓存、mock 服务）用 docker-compose.test.yml 单独定义，不和开发或生产配置混用。例如：
- 用
postgres:15和redis:7-alpine启动轻量实例，挂载初始化 SQL 或 Redis dump - 禁用持久卷或使用
tmpfs，确保每次测试干净启动、不留状态 - 暴露健康检查端口（如
/health），CI 脚本可通过curl -f http://db:5432/readyz等待服务就绪
在 .gitlab-ci.yml 中编排测试流程
GitLab CI 不需要手动启停容器，而是通过 docker-compose -f docker-compose.test.yml up -d 启动环境，再用 docker-compose run 执行测试命令。典型写法：
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
- 指定 runner 使用
dockerexecutor，并开启docker:dind服务（需提前配置） - 测试 job 分三步：构建应用镜像 → 启动测试依赖 → 运行测试容器（挂载源码或使用已构建镜像）
- 加
after_script清理：docker-compose -f docker-compose.test.yml down -v，避免残留影响下一次运行
让测试真正“自动化”而非“自动跑”
光跑通不够，要能定位问题。建议：
- 测试命令加上
--junitxml=test-results.xml（pytest）或生成覆盖率报告（coverage xml），上传到 GitLab 的 JUnit Test Reports 和 Coverage Report 区域 - 失败时自动保存容器日志：
docker-compose -f docker-compose.test.yml logs > test-logs.txt，作为 artifact 保留 - 对 flake8、mypy 等静态检查也设为独立 job，失败即阻断后续测试，避免低级错误进入集成环节
注意权限与资源隔离
本地开发用 docker-compose up 很方便，但 CI 中必须谨慎：
- 不要在 CI 中使用
host网络模式；统一用bridge并显式声明 service 别名（如db），避免 DNS 解析失败 - runner 宿主机若内存紧张，可在
docker-compose.test.yml中限制容器资源：mem_limit: 512m、cpus: 0.5 - 敏感配置（如测试数据库密码）走 GitLab CI 变量，不要硬编码；用
env_file或environment:注入，避免泄露到镜像层
