用途：在 CI/CD 中运行 OroCommerce 6.1 的 Behat 测试。Oro 公开 CI 仅支持 Jenkins；GitLab CI 可用但属社区方案，上游问题 oroinc/platform#954 自 2.x 起未解决。
平台选择：全新项目且无既有约定时用 Jenkins，维护成本最低；企业默认 GitLab 时用 DinD 中 docker compose up；不要使用 GitLab 原生 services 关键字，它无法表达 Oro 的 compose 扇出。
格式化器：始终同时运行两种，pretty 供人工查看日志，junit 供 CI 报告：bin/behat -f pretty -o std -f junit -o var/behat/junit --strict。--strict 会在未定义和待定步骤上使构建失败，否则骨架步骤会静默累积成技术债。
服务编排：Oro 需要多服务互联，compose-common.yaml 定义它们，根 compose.yaml 通过 include: 由 ORO_FILE_STORAGE_SERVICE、ORO_SEARCH_SERVICE、ORO_MQ_SERVICE 环境变量驱动扇出。典型服务含 behat、consumer、operator、chrome（selenium/standalone-chrome，需挂载 Oro 自定义扩展）、waf-behat。
Jenkins 模式：sh 'docker compose up --exit-code-from behat behat'，随后用 docker cp 提取 behat 容器中的 var/behat 作为产物，--exit-code-from 不传递文件状态。
GitLab CI：使用 docker:dind，从内部运行 docker compose up；缓存 composer、vendor；拉取 init-test 镜像获得数据库状态。
镜像：oroinc/docker-build 产出 runtime、test、init、init-test 四种变体，init 镜像预载 prod 数据库与 MongoDB，init-test 为 test 环境，作为跨任务状态传递手段，可跳过每次 5–10 分钟的 oro:install。
主要陷阱：GitLab 原生 services 会静默失败；不加 --strict 会漏过未定义步骤；并行与消费者争用（8 分片×2 消费者=16 个 MQ worker）；缺少 Chrome 扩展挂载导致模糊 JS 错误；未配置内部 GitLab token 时私有 composer 包无法解析；不使用 init-test 快照浪费时间；ChromeDriver 用 :latest 会漂移，应固定完整版本；内存限制建议 memory_limit=-1。
限制与未提供：具体版本号、完整流水线模板、各环境细节需查阅随附参考文件（jenkins-canonical.md、gitlab-ci.md、compose-fanout.md、chrome-headless.md、v6.1.md、v7.0.md 为占位）。