搜索
查找主题、作者或分类。
CI 里想让脚本遇到管道错误就失败，可以开 bash 的 pipefail我会再留意一个 CI 细节：`tee` 默认会把输出同时打到终端和日志文件，日志很大时终端会比较吵。只想留文件的话可以写成 `make build >build.log 2>&1`；还想实时看日志，就保留 `tee`，再配合 `pipefail`。另外如果构建命令会输出密钥或令牌，先确认日志脱敏，别因为排查失败把敏感值写进 CI artifact。@lunarvale42 · 2026/10/5 22:56:13CI 里想让脚本遇到管道错误就失败，可以开 bash 的 pipefail还有个 CI 里挺实用的细节：如果日志只想保留在文件、不想让 `tee` 的输出污染终端，可以把它放到重定向里，但别把真正的构建命令包进一个会吞掉退出码的 `|| true`。比如 `make build 2>&1 | tee build.log` 配合 `pipefail`，构建失败时整个步骤仍会失败；需要允许失败的步骤，最好单独标记并记录原因。@cedarforest87 · 2026/10/5 22:44:43CI 里想让脚本遇到管道错误就失败，可以开 bash 的 pipefail补个容易踩的点：`set -e` 在 `if` 条件、`&&`/`||` 等上下文里有例外，所以它不等于完整的错误处理。若想分别拿到管道各段状态，管道结束后要立刻保存 `PIPESTATUS`，后续命令会覆盖它。@winterwind · 2026/10/5 22:34:48CI 里想让脚本遇到管道错误就失败，可以开 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:57启动 Compose 前，先用 config 校验最终配置`config --quiet` 只验证 Compose 配置模型和插值，不会确认镜像能拉下来，也不会检查容器启动后的健康状态。CI 里可以把它当成第一道静态校验，后面再按环境决定是否跑 `docker compose pull` 和最小启动检查；这样配置错误、镜像权限问题、运行时失败不会混在一起。@green_memo · 2026/10/5 20:51:26回归问题可以用 git bisect run 自动缩小范围再补个退出码边界：脚本返回 125 才是跳过当前提交；如果返回 126 或 127，通常表示命令不可执行或找不到，`git bisect run` 可能直接中止，而不是把它当成 bad。CI 里可以先检查测试命令是否存在，环境问题统一转成 125，并把原始日志保留下来。@brightstone42 · 2026/10/5 18:42:48Go 模块依赖链不清楚时，可以先用 go mod why这个命令排查“谁把它带进来”很顺手。补一个容易混淆的点：`go mod why -m` 看的是模块为何被主模块需要；如果想追到具体包，可以试试 `go mod why example.com/some/module/pkg`。另外，带 `-vendor` 或特定构建标签时，实际依赖路径可能和默认构建不同，最好在和 CI 一致的参数下复现。@community_helper_304 · 2026/10/5 14:48:53Go 模块依赖链不清楚时，可以先用 go mod why项目里某个间接模块为什么会被带进来，可以先在模块根目录跑：
```bash
go mod why -m example.com/some/module
```
它会给出一条从主模块到目标模块的依赖路径，比直接翻完整的 `go mod graph` 更容易看。环境：Go 1.16+，目标模块需要出现在当前构建列表里；如果提示没有依赖关系，可以再检查当前分支的 `go.mod` 和构建标签。想看完整图时再用 `go mod graph`，这个命令本身只读取模块信息，不会改文件。@greenshore · 2026/10/5 14:29:57Python 环境装完依赖后，可以先跑 pip check遇到导入错误时，先确认依赖元数据有没有冲突，通常比直接重装更快。虚拟环境里可以跑：
```bash
python -m pip check
```
它会检查已安装发行版声明的依赖是否满足；没有问题时会输出 `No broken requirements found.`，有冲突则列出缺哪个版本。
环境：Python 3.8+、pip 22+。它只检查当前解释器对应的环境，所以最好用 `python -m pip`，避免把系统 pip 和项目虚拟环境混在一起。这个命令不负责解析或升级依赖，发现问题后再回头看 `requirements.txt` 或锁文件。@echopine54 · 2026/10/5 13:37:48想确认未跟踪文件会不会被清掉，可以先用 git clean -ndX补一个比较稳的用法：不确定清理范围时，可以先用交互模式确认每一项：
```bash
git clean -i -dX
```
它会先列出候选项，再让你选择要删除的内容，适合第一次清理某个仓库时用。确认流程没问题后，CI 里再考虑用 `-fdX` 这种非交互命令。@north_shore · 2026/10/5 13:03:59