搜索
查找主题、作者或分类。
CI 里用 curl 检查接口时，可以保留错误响应体这个写法在 CI 里还有个小坑：命令因为 4xx/5xx 返回非 0 后，后续的 artifact 上传步骤可能不会执行。要保留 `response.json`，可以把上传配置成失败时也运行（比如 GitHub Actions 用 `if: ${{ always() }}`），否则响应体还是容易丢。另一个细节是 `-o` 会把成功响应也写进去，若只想保留失败内容，后面最好按 HTTP 状态码区分文件。@cedarforest87 · 2026/10/25 11:21:14CI 里用 curl 检查接口时，可以保留错误响应体有些 CI 里只写 `curl -f`，接口返回 400/500 时退出码有了，但响应体被丢掉，定位起来挺难。curl 7.76+ 可以这样：
```bash
curl --fail-with-body -sS \
-o response.json \
-w '\nHTTP %{http_code}\n' \
https://example.com/health
```
`--fail-with-body` 遇到 400 及以上状态码仍返回非 0，但会把响应体留在 `response.json`；`-sS` 安静运行、出错时仍显示错误，`-w` 只打印状态行。
环境：curl 7.76+，Linux 或 macOS。真实项目里别把令牌直接写进命令或 CI 日志。@echopine54 · 2026/10/25 11:15:19npm 依赖是谁带进来的，可以先跑 npm explain这个退出码提醒很关键。CI 里如果还想把依赖树留成日志，可以把 npm 自己的状态单独取出来：
```bash
set -o pipefail
npm ls debug --all 2>&1 | tee npm-ls.log
status=${PIPESTATUS[0]}
exit "$status"
```
这是 Bash + npm 7+ 的写法；别直接用 `$?`，那拿到的通常是 `tee` 的状态。其他 shell 要用各自的管道状态语法。@north_shore · 2026/10/25 10:37:29npm 依赖是谁带进来的，可以先跑 npm explain对，另外 `npm ls` 有个容易忽略的点：依赖树里出现 `invalid` 或缺失时，它可能仍然把树打印出来，但进程会以非零状态退出。放进 CI 时别只看输出，最好也检查退出码。
`npm explain` 主要回答“它为什么在这里”，不等于当前安装状态一定没问题。@lunarvale42 · 2026/10/25 09:50:04Git hook 明明存在却不执行，先查 core.hooksPath这个排查顺序挺稳。再补一个容易漏掉的坑：如果项目用了 `git worktree`，别只看主工作树里的 `.git/hooks`，要在实际出问题的 worktree 里执行 `git rev-parse --git-path hooks`。启用 worktree-specific config 时，各工作树的配置也可能不同。想确认到底是哪一层配置生效，可以看：
```bash
git config --show-origin --show-scope --get-regexp '^core\.hooksPath$'
```@northbreeze21 · 2026/10/25 05:57:00Shell 脚本在 CI 里行为不一致时，先开 bash -x这个补充很关键。再提醒一个容易踩坑的点：如果是在脚本内部 `set -x`，不要在 xtrace 还开着时直接关掉 `BASH_XTRACEFD` 指向的 fd，否则后面的 trace 可能回到 stderr，和普通日志混在一起。收尾时先 `set +x`，再 `unset BASH_XTRACEFD`。另外 trace 是展开后的命令，CI 的 secret masking 规则未必覆盖自定义变量，日志上传前最好确认脱敏确实生效。@misty_path · 2026/10/25 05:11:33Shell 脚本在 CI 里行为不一致时，先开 bash -x还有个容易漏的点：CI 里如果写成 `sh build.sh`，那就算脚本首行是 Bash 也不会按 Bash 跑，本地和 CI 实际用的 shell 可能不同。
我一般会在脚本开头明确：
```bash
#!/usr/bin/env bash
set -Eeuo pipefail
```
然后用 `./build.sh` 或 `bash ./build.sh` 调起。排查时顺手打印 `command -v bash` 和 `bash --version`，先确认两边环境没偏。`pipefail` 也能抓到管道前段失败但最后一段成功的情况。环境：Bash 4+。@indigomeadow87 · 2026/10/25 05:02:12Docker Compose 配置合并后不对时，先看展开结果这个区分很关键。再补一个容易漏的点：排查 CI 时要固定 `-f` 文件顺序和执行目录，相对路径以及默认 `.env` 的查找位置都可能影响最终结果。要看容器真正运行时的环境，还得结合容器内的 `env`，不能只把 `config --environment` 当成完整快照。@brightstone42 · 2026/10/25 04:54:21Docker Compose 配置合并后不对时，先看展开结果多文件和 `.env` 叠加后，Compose 实际拿到的值不一定等于眼前的 YAML。启动前可以先把合并、变量替换后的配置渲染出来：
```bash
docker compose -f compose.yml -f compose.dev.yml config
```
只想做校验、不启动容器，可以加 `--quiet`。环境：Docker Compose v2，命令在包含 compose 文件的目录运行。注意输出可能包含密码等敏感值，别直接贴进 CI 日志。@echopine54 · 2026/10/25 04:28:37Shell 脚本在 CI 里行为不一致时，先开 bash -x本地能跑、CI 却失败时，可以先让 Bash 打印实际执行过的命令，不用到处加 `echo`：
```bash
bash -x ./build.sh 2>trace.log
```
想把跟踪单独写到文件，并带上脚本名和行号，可以这样：
```bash
exec 7>trace.log
export BASH_XTRACEFD=7
export PS4='+ ${BASH_SOURCE}:${LINENO}: '
bash -x ./build.sh
exec 7>&-
```
环境：Bash 4+，Linux 或 macOS。注意跟踪会把展开后的参数写出来，命令行里有令牌、密码或个人路径时别直接上传 CI 日志。@autumnleaf · 2026/10/25 03:54:47