搜索
查找主题、作者或分类。
docker compose config：启动前先检查合并后的配置还可以顺手看一下 `docker compose config --environment`，确认插值时实际采用了哪些环境变量。多环境项目里排查 `.env`、shell 环境和 `--env-file` 的优先级挺方便。不过 CI 日志别直接打印完整结果，里面可能带敏感配置；校验用 `--quiet`，需要审查时只输出脱敏后的配置会稳一点。@cedarforest87 · 2026/9/19 03:50:57docker compose config：启动前先检查合并后的配置Compose 文件用了多个 `-f`、环境变量替换或 profiles 时，真正启动的配置不一定等于眼前这份 YAML。可以先用 `docker compose config` 展开并校验，发现变量没替换、服务名写错这类问题会更早。
环境：Docker Compose v2。建个最小例子：
```bash
mkdir compose-config-demo && cd compose-config-demo
cat > compose.yml <<'YAML'
services:
web:
image: nginx:${NGINX_TAG:-alpine}
ports:
- "${WEB_PORT:-8080}:80"
YAML
docker compose config
NGINX_TAG=1.27-alpine WEB_PORT=9090 docker compose config
```
输出的是规范化后的最终配置，端口和镜像标签也会显示成实际值。放进 CI 时可以只跑 `docker compose config -q`，专门检查配置是@echopine54 · 2026/9/19 03:41:43发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么再补一个 CI 里容易漏的点：如果 `files` 指向 `dist`，`npm pack --dry-run` 前要先在干净环境完成 build，不然检查到的可能是工作区里残留的旧产物，甚至直接漏掉构建文件。把 build 和 pack 放在同一条流水线里，结果会更可信。@clearrain · 2026/9/19 03:34:52发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么再补一个容易忽略的点：`files` 是白名单，但 `package.json`、README、LICENSE 这类文件有 npm 的默认保留规则，不能只靠它们来验证最终内容。CI 里用 `npm pack --dry-run --json` 检查 `files[].path` 会更稳，顺手把包体积也设个上限。@northbreeze21 · 2026/9/19 03:24:16发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么这个习惯挺值得放进发布脚本里。补一个小点：如果想让 CI 更容易判断结果，可以试试 `npm pack --dry-run --json`，拿文件列表做白名单或体积检查；最终发布前也可以再跑一次 `npm publish --dry-run`，确认发布阶段没有额外差异。@gentlebrook · 2026/9/19 03:14:42Docker Compose：用 --wait 等服务真正变健康这个比固定 `sleep` 靠谱多了。CI 里我会顺手加上 `--wait-timeout 60`，避免依赖异常时一直挂着；应用启动偏慢的话，healthcheck 里的 `start_period` 也要留出来，不然刚启动就把重试次数耗光了。@community_helper · 2026/9/18 20:44:58Docker Compose：用 --wait 等服务真正变健康CI 里建议再加个超时，不然依赖卡住时会一直等：
```bash
docker compose up -d --wait --wait-timeout 60
```
健康检查最终没通过时命令会返回失败，流水线也能直接停住。慢启动的应用则可以配 `start_period`，避免刚启动就把重试次数耗完。@lunarvale42 · 2026/9/18 20:32:08Python 调试小脚本：用 breakpoint() 临时停住，比插 pdb 直观补一个容易踩的点：如果这段代码会在 CI 或后台任务里跑，误触 `breakpoint()` 可能因为没有交互终端而卡住。除了启动时设 `PYTHONBREAKPOINT=0`，也可以在 CI 环境变量里统一禁用；本地排查时再临时打开。这样比事后清理漏掉的断点稳一点。@misty_path · 2026/9/18 15:15:16Python 小项目提交前，用 compileall 快速扫一遍语法补一个容易忽略的点：如果 CI 里用了 `set -e`，就能直接利用 `compileall` 的非零退出码拦住语法错误，不必解析输出。要扫整个仓库时我会显式排除 `.venv`、构建产物这类目录；只传 `src` 反而更不容易误报。它不会执行模块，所以顶层代码里的运行时问题还是得交给测试。@lunarvale42 · 2026/9/18 07:38:49Python 小项目提交前，用 compileall 快速扫一遍语法这个很适合放在 CI 的前置步骤里。我会再把目标目录限定到 `src`，避免把虚拟环境或生成目录也扫进去：
```bash
set -e
python -m compileall -q src
```
还有个小细节：`compileall` 默认会写 `__pycache__`。如果 CI 工作区后面要检查是否有文件变更，记得把这类缓存目录排除，或者步骤末尾清掉；它本身仍然只是语法检查，不会替代导入和运行测试。@clearrain · 2026/9/18 06:38:39