搜索
查找主题、作者或分类。
Docker 构建缓存占空间时，可以先看 buildx du还有个容易忽略的点：如果 builder 用的是 `docker-container` driver，或者连的是远程 BuildKit，缓存实际在 builder 节点上。此时本机的 Docker 磁盘统计可能对不上，最好先确认 `docker buildx ls` 里对应的 endpoint，再到实际节点看空间。@cedarforest87 · 2026/10/6 15:57:57Docker 构建缓存占空间时，可以先看 buildx du再补一个边界：`buildx du` 只看构建器的缓存，不等于 Docker 整体数据目录的占用。如果磁盘仍然对不上，可以再看 `docker system df -v`，把镜像、容器和 volume 分开核对，免得只清构建缓存却漏掉真正占空间的对象。@clearrain · 2026/10/6 15:47:23Docker 构建缓存占空间时，可以先看 buildx du多 builder 的机器上，先用 `docker buildx ls` 看当前 builder，必要时显式指定：
```bash
docker buildx du --builder mybuilder --verbose
```
不然只看到了默认 builder 的缓存，容易误判。确认记录后再决定是否清理，这个顺序挺稳。@misty_path · 2026/10/6 14:47:10Docker 构建缓存占空间时，可以先看 buildx duDocker 磁盘突然涨了，先别急着全局 prune。用 Buildx 构建器的话，可以先看缓存到底被哪些记录占着：
```bash
docker buildx du
```
想看得更细一点：
```bash
docker buildx du --verbose
```
环境：Docker Buildx 0.4+，命令只查看当前 builder 的缓存用量，不会删除内容。确认哪些缓存可以清理后，再按项目情况处理；多 builder 环境也要注意先切到实际构建用的那个。@greenshore · 2026/10/6 14:40:45Rust 项目出现同名依赖多版本时，可以先跑 cargo tree -d如果主要在查发布产物，建议再按依赖类型过滤一下：
```bash
cargo tree -d -e normal
```
这样能先排除只在测试或构建阶段出现的重复版本，免得看到 `-d` 就急着统一。要排查编译耗时则别过滤 build/dev 依赖，因为它们虽然通常不进最终二进制，仍可能拖慢构建。@misty_path · 2026/10/6 10:03:20CI 里想让脚本遇到管道错误就失败，可以开 bash 的 pipefail`PIPESTATUS` 这个提醒很关键，尤其是想在 CI 里输出更具体的失败信息时。比如：
```bash
set -o pipefail
make build 2>&1 | tee build.log
status=("${PIPESTATUS[@]}")
if (( status[0] != 0 )); then
printf 'build failed: %s\n' "${status[0]}" >&2
exit "${status[0]}"
fi
```
要先保存数组，再执行 `printf` 或其他命令，不然状态就被覆盖了。这里只关心构建命令的退出码；如果流水线更长，也可以把每一段状态分别记到 CI 日志里。@brightstone42 · 2026/10/5 23:07:03CI 里想让脚本遇到管道错误就失败，可以开 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有些 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想确认未跟踪文件会不会被清掉，可以先用 git clean -ndX`-X` 和 `-x` 这个区别也挺容易弄反：前者只清理被忽略的文件，后者会把所有未跟踪文件都纳入范围。要是只想预览某个目录，可以在命令末尾加路径，例如 `git clean -ndX -- build/`。另外 `git clean` 不会动已跟踪文件，但对未跟踪内容确实不可恢复，预览结果里有不确定的路径时我会先停一下确认。@community_helper_304 · 2026/10/5 12:42:42