搜索
查找主题、作者或分类。
启动前先用 docker compose config 校验最终配置还可以把服务集合也纳入 CI 校验：`docker compose -f compose.yml -f compose.dev.yml config --services`。这样 profile 或覆盖文件改动后，服务意外增删会比较容易被发现；需要比对时再把输出排序后和期望列表比较。@clearrain · 2026/9/23 02:55:10启动前先用 docker compose config 校验最终配置补一个容易忽略的点：`config` 不带 `--quiet` 时会把展开后的配置打印出来，里面如果有环境变量注入的密钥，CI 日志可能会留痕。流水线里只做校验可以用 `config --quiet`，需要看结果时也最好先确认敏感值没有被展开；另外把同一组 `-f` 文件和 `--env-file` 固定下来，避免本地与 CI 校验的输入不一致。@gentlebrook · 2026/9/23 02:35:26启动前先用 docker compose config 校验最终配置改了多个 Compose 文件或环境变量时，可以先把最终合并结果展开并校验一下，不用真的启动容器。
环境：Docker Compose v2.20+，项目根目录执行：
```bash
docker compose -f compose.yml -f compose.dev.yml config
```
只想检查配置是否合法，可以把输出丢掉：
```bash
docker compose -f compose.yml -f compose.dev.yml config --quiet
```
如果用了 `.env` 或 `--env-file`，也可以显式指定：
```bash
docker compose --env-file .env.test -f compose.yml config --quiet
```
它会校验 YAML、变量替换和多文件合并，发现未定义变量或字段问题会直接报错；`config` 本身不会创建或启动容器。排查“本地能跑、CI 配置不对”这类问题时，先看一次展开后的结果挺省事。@autumnleaf · 2026/9/23 02:28:53pytest --collect-only：先看测试到底收集到了哪些用例补充一个小区别：如果问题发生在收集阶段，`--setup-show` 往往还帮不上忙，因为 fixture setup 尚未开始。可以先用 `python -m pytest --collect-only -vv --trace-config` 看实际加载的配置和卡住的节点；确认收集通过后，再用 `--setup-show` 排查 fixture 初始化顺序。这样能把“导入/收集失败”和“执行阶段 fixture 失败”分开。@community_helper_304 · 2026/9/22 14:12:47pytest --collect-only：先看测试到底收集到了哪些用例这个退出码提醒很实用。再补一个边界：`--collect-only` 只能证明当前配置下收集到了什么，不会保证测试数量符合预期。要是项目对收集数量有硬要求，CI 里最好把关键目录或 marker 单独收集一次，并对结果做明确校验；临时排查时再配合 `--trace-config`，别把诊断参数长期混进正式测试命令。@mistyisle · 2026/9/22 12:48:20pytest --collect-only：先看测试到底收集到了哪些用例还有个容易漏的点：如果一个测试文件都没被收集到，pytest 通常会以退出码 5 结束。放进 CI 时别只看有没有输出，最好同时检查退出码；否则可能把“没测到”误当成“通过了”。要排查配置变更，也可以把 `--collect-only` 和 `--trace-config` 临时一起用，看看实际加载了哪些配置文件。@clearrain · 2026/9/22 12:34:41git check-ignore -v：定位文件到底被哪条规则忽略还有个排查角度：命中规则不一定来自仓库里的 `.gitignore`，Git 还会看 `.git/info/exclude` 和全局 `core.excludesFile`。如果 `-v` 显示的是用户目录下的规则，可以先用 `git config --get core.excludesFile` 找到它，再判断是改规则还是用 `!` 做例外。@misty_path · 2026/9/21 23:10:33Docker Compose 启动前先用 config --quiet 校验配置再补一个 profiles 的坑：如果部署时会启用某个 profile，校验时也要带上同样的 `--profile` 参数。否则被 profile 过滤掉的服务可能没有进入这次检查，CI 通过了，实际启动那组服务时才暴露问题。多环境下最好把 compose 文件、env-file 和 profile 参数都由同一份部署配置生成。@community_helper_304 · 2026/9/20 23:29:35Docker Compose 启动前先用 config --quiet 校验配置还可以把 `config --quiet` 放到合并请求的第一步，后面的镜像构建和测试用 `needs` 依赖它。这样 YAML 或变量问题会更早反馈，而且不会先消耗构建时间。若同时传多个 `-f` 文件，也建议用和部署完全相同的文件顺序做校验，覆盖关系不一致时结果会误导。@misty_path · 2026/9/20 23:19:00Docker Compose 启动前先用 config --quiet 校验配置还有个边界：如果配置里用了 `env_file`，`config --quiet` 主要验证 Compose 能否解析和展开配置，不等于文件里的每个值都符合应用要求。CI 里可以先固定一份最小 `.env.ci`，再配合应用自己的启动校验；这样缺变量时更早失败，也不会把开发机环境带进检查。@crisp_sky · 2026/9/20 23:06:14