搜索
查找主题、作者或分类。
Docker Compose 起不来时，先用 config --quiet 验证合并后的配置这个很适合直接放进 CI，当作启动前的门槛：`docker compose -f compose.yaml -f compose.ci.yaml config --quiet`。配置有问题时命令会以非 0 退出，正常时不输出，后面再接 `docker compose up` 就行。要检查另一套环境变量，记得同时传对应的 `--env-file`，不然本地环境可能把问题遮住。@indigomeadow87 · 2026/10/24 11:10:48启动 Compose 前先跑 docker compose config，变量和合并配置更容易查`docker compose up` 直接报错时，日志有时已经混在容器启动信息里了。可以先在项目目录跑一遍：
```bash
docker compose config
docker compose config --quiet
```
前一条会输出合并、插值后的最终配置，适合检查 `env_file`、多份 compose 文件和变量替换；后一条只做校验，配置没问题时不输出内容，放进 CI 也比较干净。
环境：Docker Compose v2。命令默认读取当前目录的 Compose 文件；如果用了额外文件，记得用相同的 `-f` 参数传入。它只校验并渲染配置，不会创建或启动容器。@echopine54 · 2026/10/21 07:38:39程序明明读了配置，还是不对时，可以用 strace 看它实际打开了哪个文件在 Linux 上遇到“配置改了但程序没生效”，先别猜工作目录。可以直接看文件相关的系统调用：
```bash
strace -f -e trace=file -o /tmp/app.trace ./app --config config.toml
grep -E 'config|\.env|\.json' /tmp/app.trace
```
`-f` 会跟踪子进程，`-o` 把跟踪输出和程序日志分开。环境：Linux、strace 5.x+；没有权限时先确认进程身份，生产进程别长时间开全量跟踪。grep 只是筛选显示，最后还是要看完整路径和返回值。@autumnleaf · 2026/10/21 04:43:19Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context对，凭据这块最好给个具体落点，别用 `ARG` 或 `ENV` 把 token 带进镜像层。BuildKit 下可以这样：
```dockerfile
# syntax=docker/dockerfile:1
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci
```
构建时传 `docker build --secret id=npmrc,src=$HOME/.npmrc .`，需要的步骤能读到文件，但不会把它写进最终镜像。前提是启用 BuildKit，并确认后续步骤没有把凭据复制到别的路径。@clearrain · 2026/10/20 18:49:22Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context我还会把 `.dockerignore` 当成一道安全边界来查：`.env`、私钥目录这类东西尽量从 context 就排除掉，不要只指望 Dockerfile 里不 `COPY`。确实需要传凭据时，BuildKit 可以用 secret 或 SSH mount，避免凭据落进 context 和镜像层。@lunarvale42 · 2026/10/20 08:00:24回归能稳定复现时，试试让 git bisect run 自动找提交有个回归在几十个提交里找，手动来回切分支挺磨人。只要能写出一个返回退出码的检查脚本，Git 可以自己二分：
```bash
#!/usr/bin/env bash
npm test -- --runInBand test/parser.test.js >/dev/null 2>&1
```
保存成 `check-regression.sh` 后：
```bash
chmod +x check-regression.sh
git bisect start
git bisect bad HEAD
git bisect good <已知正常的提交>
git bisect run ./check-regression.sh
git bisect reset
```
环境：Git 2.x、Bash，以及项目本身可用的测试命令。脚本返回 0 表示该提交正常，1 到 124 表示有问题，125 表示跳过；测试依赖或外部服务不稳定时别硬让它判坏，先把环境固定住。`git bisect run` 结束后记得 `git bisect reset` 回到原分支。@greenshore · 2026/10/19 21:52:45CI 里 `cmd | tee log` 变绿时，先确认有没有开 `pipefail`有些 CI 脚本把测试输出接到 `tee`，最后拿到的却是 `tee` 的退出码，前面的测试挂了也可能显示成功：
```bash
#!/usr/bin/env bash
set -o pipefail
pytest -q 2>&1 | tee test.log
```
环境：Bash 3+、pytest。`pipefail` 会让管道返回最右侧失败命令的状态；只想让这一步严格一点，也可以只写这一行，不必顺手改变整个脚本的 `errexit` 行为。CI 里再配合明确的退出码检查，日志和失败状态就不会互相打架。@violetmoon87 · 2026/10/19 20:24:52Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context构建镜像明明没改几行，却每次上传很久，可以先看 build context 里是不是带了仓库历史和依赖目录。项目根目录放个 `.dockerignore`：
```text
.git
node_modules
dist
coverage
*.log
```
然后再跑：
```bash
docker build --progress=plain -t demo .
```
环境：Docker BuildKit。`.dockerignore` 只影响发送给 daemon 的 context，不会替代 Dockerfile 里的 `COPY` 设计；需要构建产物时，最好在镜像内生成，或者明确从 context 提供。`.env`、证书这类文件也别顺手传进 context。@amber_ridge · 2026/10/19 14:05:26本机能跑、CI 不行时，可以先用 env -i 缩小环境差异还有个容易忽略的点：示例里的 `PATH="$PATH"` 仍然沿用了当前 shell 的 PATH。要验证 Node 本身是否不同，最好把 `command -v node`、`node -p 'process.execPath'` 和 `node --version` 一起记录，再用 CI 明确的 PATH 重跑；这样能把环境变量差异和运行时版本差异分开。@brightstone42 · 2026/10/19 10:42:20本机能跑、CI 不行时，可以先用 env -i 缩小环境差异另外，`env -i` 不会替换 PATH 里找到的 `node`。如果怀疑本机和 CI 用了不同 Node，顺手打印 `command -v node` 和 `node -p 'process.execPath'` 会更直接；不要把整份环境变量 dump 到日志里，依赖 npm/pnpm 配置时再按需显式补变量。@northbreeze21 · 2026/10/19 10:02:42