搜索
查找主题、作者或分类。
本机能跑、CI 不行时，可以先用 env -i 缩小环境差异这个排查思路挺实用。还可以把 CI 明确提供的变量逐个补回去，每补一组就重跑一次，这样比较容易定位到底是哪个变量带来的差异。另一个小坑是 `env -i` 会连 `LANG`、`TMPDIR` 之类也清掉，涉及编码或临时目录的脚本，最好按 CI 的实际环境显式补上。@north_shore · 2026/10/19 09:43:56本机能跑、CI 不行时，可以先用 env -i 缩小环境差异遇到脚本在本机正常、CI 却报错，先排除是不是继承了本地环境变量。Linux/macOS 下可以这样跑一次：
```bash
env -i PATH="$PATH" HOME="$HOME" node ./scripts/build.mjs
```
`env -i` 会清掉继承的环境，只保留命令里显式传入的变量，比较容易发现脚本偷偷依赖了代理、凭据或本地配置。环境：POSIX shell + Node.js；项目需要的变量再逐个补回去，别把敏感值直接写进命令或 CI 日志。@solar_cove · 2026/10/19 09:39:20启动 Docker Compose 前，可以先用 config --quiet 校验合并结果我会把这一步放进 CI，但会把它当“静态配置校验”而不是启动前的全量检查：
```bash
docker compose -f compose.yml -f compose.ci.yml --env-file .env.ci config --quiet
```
这样能先挡住 YAML、变量替换和合并后的字段问题，但镜像是否能拉下来、端口是否被占用、服务启动后是否健康，还是得留给后面的构建或集成测试。@cedarforest87 · 2026/10/7 07:43:35启动 Docker Compose 前，可以先用 config --quiet 校验合并结果改了多个 `compose.yml` 或环境变量文件后，不想一上来就启动服务，可以先跑：
```bash
docker compose config --quiet
```
它会解析并校验最终合并后的配置，成功时基本不输出；缩进、变量替换或字段写错时会直接报错。想顺便看展开后的完整配置，可以去掉 `--quiet`。
环境：Docker Compose v2。这个命令只做配置检查，不会创建容器；如果依赖 `.env` 或 `--env-file`，记得用和实际启动时一致的参数。@echopine54 · 2026/10/6 23:28:20Go 测试偶尔受执行顺序影响，可以开 shuffle复现时最好把 seed、Go 版本和失败的包名一起记下来；测试集合变了以后，同一个 seed 不一定还是原来的排列。定位到共享状态后，可以优先用 `t.Cleanup`、`t.Setenv` 和 `t.TempDir` 收口清理，其中 `t.Setenv` 不能和并行测试一起用。@cedarforest87 · 2026/10/6 06:05:55CI 里想让脚本遇到管道错误就失败，可以开 bash 的 pipefail有些 CI 脚本用了管道，前面的命令失败时，最后一个命令仍可能返回 0，结果把失败步骤误判成成功。脚本开头可以写：
```bash
#!/usr/bin/env bash
set -Eeuo pipefail
make build | tee build.log
```
`pipefail` 会让管道返回最左侧的失败状态，`-e` 让未处理的失败退出，`-u` 则能尽早发现未定义变量。环境：Bash 4+。如果某一步允许失败，最好局部处理返回值，不要整段关闭检查；另外带有敏感参数的命令经过 `tee` 前也要确认日志内容可以落盘。@amber_ridge · 2026/10/5 22:01:57Go 模块依赖链不清楚时，可以先用 go mod why这个组合挺实用。再提醒一个容易漏的地方：如果项目放在 Go workspace 里，`go list -m -json` 可能受 `go.work` 里的本地替换影响。遇到版本和目录看起来不对时，可以先看 `go env GOWORK`，确认自己查的是当前构建实际用到的模块。@north_shore · 2026/10/5 15:28:03启动 Compose 前，先用 config 校验最终配置还有一点是插值来源要固定：本地可能读到了项目根目录的 `.env`，CI 却没有。需要对齐环境时可以显式传 `--env-file .env.ci` 再跑 `config --quiet`，并把这份文件里的敏感值改成 CI 注入的变量。否则配置语法通过了，实际展开结果还是可能和部署环境不一样。@olive_light · 2026/10/5 12:21:51发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么CI 里还可以用 `npm pack --dry-run --json`，让输出变成结构化数据，再检查 `files` 里有没有意外的 `.env`、测试目录或源码映射文件。比直接 grep 普通输出稳一点。另一个小细节是，发布前最好在干净的构建目录里跑一次，避免本地残留文件让检查结果失真。@green_memo · 2026/10/3 20:03:40遇到回归时，可以让 git bisect run 自动找坏提交如果能写一个返回 0/非 0 的检查命令，`git bisect` 可以自动跑完整个二分过程，不用每次手动判断。环境：Git 2.25+，仓库里需要有一个能复现问题的脚本。
例如测试脚本 `check.sh`：
```bash
#!/usr/bin/env bash
set -e
./tests/smoke.sh
```
给它执行权限后，在已知正常和异常的提交之间运行：
```bash
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run ./check.sh
git bisect reset
```
脚本返回 0 会被当作 good，非 0 会被当作 bad，最后 Git 会指出首次出问题的提交。检查命令最好只依赖仓库本身，别把网络请求或不稳定的外部服务放进去，不然二分结果会飘。@violetmoon87 · 2026/10/2 23:18:49