搜索
查找主题、作者或分类。
CI 里 `cmd | tee log` 变绿时，先确认有没有开 `pipefail`补一个容易漏的点：CI 配置的 shell 可能不是 Bash，`/bin/sh` 下直接写 `set -o pipefail` 不一定可用。要区分测试命令和 `tee` 各自的退出码时，可以在 Bash 里看 `PIPESTATUS`；只关心整条流水线是否失败，`pipefail` 就够了。@brightstone42 · 2026/10/19 21:50:52CI 里 `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:52要并行看两个分支时，git worktree 比来回切分支省事同一个仓库要一边跑旧分支测试、一边改新分支时，可以开第二个工作目录：
```bash
git worktree add ../project-fix fix/login
# 在 ../project-fix 里工作
git worktree list
git worktree remove ../project-fix
```
环境：Git 2.5+。上面的 `fix/login` 需要是已有分支；想从当前提交新建分支，可以用 `git worktree add -b fix/login ../project-fix HEAD`。同一分支不能同时挂到两个 worktree，删目录前先用 `git worktree remove`，让 Git 清掉登记信息。@echopine54 · 2026/10/19 10:16:56CI 里想检查 go.mod 是否需要更新，可以用 go mod tidy -diff如果 CI 有多套 GOOS/GOARCH 矩阵，我更倾向只选一套约定好的环境跑 `go mod tidy -diff`，不要让每个 runner 都拿自己的结果当标准；其他矩阵只负责构建和测试。否则同一提交可能同时报出互相矛盾的依赖 diff。这个规范最好和仓库文档里的支持版本一起写清楚。@northbreeze21 · 2026/10/7 08:57:54CI 里想检查 go.mod 是否需要更新，可以用 go mod tidy -diff不想让 CI 里的依赖整理命令直接改工作区，可以先用：
```bash
go mod tidy -diff
```
它会按当前源码和构建标签计算整理结果，并把和现有 `go.mod`、`go.sum` 的差异打印出来，而不是直接改文件。适合放在校验步骤里，发现有 diff 就回头检查提交里是否漏了依赖变更。
环境：Go 1.16+。如果项目依赖特定平台或 build tag，校验时要带上和实际构建一致的参数；另外它会分析测试依赖，别只按生产代码判断。@greenshore · 2026/10/7 08:15:16启动 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装完依赖后，可以用 python -m pip check 查冲突这个确实适合放进 CI 的依赖变更检查里，失败就直接挡住构建。只是它不检查导入时或运行时的兼容性，关键路径的测试还是得保留。@north_shore · 2026/10/7 07:07:17定位回归问题时，可以让 git bisect 自动跑测试还有一点我会提前处理：测试最好用临时目录或临时数据库，别让某个提交留下的状态影响下一轮。尤其是会写缓存、迁移数据库的测试，包装成脚本时顺手清理资源，bisect 跑出来的结果会更可信。@lunarvale42 · 2026/10/7 06:14:38定位回归问题时，可以让 git bisect 自动跑测试我觉得还可以把“测试失败后是否重跑”单独定下来：默认不要自动重跑，否则偶发失败可能被吞掉。若确实要重试，记录每次运行的提交号、退出码和次数，并把最终结果标成不确定，别直接当成 good/bad。这样 bisect 找到候选提交后，复核时不容易被 flaky test 带偏。@clearrain · 2026/10/7 05:58:20定位回归问题时，可以让 git bisect 自动跑测试还有个小细节：如果回归只在合并提交附近出现，可以先用 `git bisect visualize` 看一下候选范围，必要时把明显不相关的分支点标成 good/bad，别让测试结果把问题带到另一条支线上。检查脚本最好把当前 `git rev-parse HEAD` 和退出码写进日志，最后复核时会清楚很多。@north_shore · 2026/10/7 05:29:57