构建记录是故障回溯、版本验证和流程审计的核心依据，须包含触发源、执行时间、环境标识、步骤状态及产物摘要，并统一归档、定时清理、支持快速查询与系统联动。
Linux 自动化部署中，构建记录不是“附属品”，而是故障回溯、版本验证和流程审计的核心依据。管理好它，等于握住了流水线的脉搏。
明确构建记录该存什么
构建记录不是日志堆砌，而是结构化信息集合。至少应包含： - 构建触发源（Git commit hash、分支名、tag 或 PR 编号） - 执行时间（精确到秒，带时区，如 `2026-06-15T13:42:08+0800`） - 运行环境标识（Jenkins job 名 / GitHub Actions workflow 名 / Shell 脚本路径 + 主机 hostname） - 关键步骤状态（拉取成功 ✅、构建失败 ❌、测试跳过 ⚠️，附 exit code） - 输出产物摘要（如生成的 `.tar.gz` 文件路径、Docker 镜像 ID、dist 目录 checksum）例如，一次 Node.js 项目构建后可生成简明元数据文件 build-info.json：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
{
"commit": "a1b2c3d",
"branch": "main",
"timestamp": "2026-06-15T13:42:08+0800",
"host": "deploy-server-01",
"exit_code": 0,
"artifact": "/opt/app/releases/v1.2.3.tar.gz",
"sha256": "e3b0c44298fc1c149afbf4c8996fb..."
}
用统一位置 + 时间戳命名归档
避免散落日志或覆盖旧记录。推荐做法： - 所有构建记录统一存放在固定路径，如 /var/log/builds/ 或项目级 ./logs/build/ - 每次构建生成独立子目录，按时间戳命名：`20260615-134208-a1b2c3d` - 同目录下存放：stdout.log（完整执行流）、build-info.json（结构化元数据）、artifact-list.txt（产物清单）
Shell 脚本中可这样创建：
BUILD_ID=$(date +"%Y%m%d-%H%M%S")-${COMMIT_HASH:0:7}
LOG_DIR="/var/log/builds/${BUILD_ID}"
mkdir -p "$LOG_DIR"
# 后续所有输出重定向至此
exec &> "$LOG_DIR/stdout.log"
保留最近 N 次，自动清理老旧记录
无限制堆积会耗尽磁盘，也降低检索效率。可用 cron 定期清理： - 每日凌晨执行：find /var/log/builds -mindepth 1 -maxdepth 1 -type d -mtime +30 -exec rm -rf {} +（保留 30 天）
- 或更精准地按数量控制（需配合 ls + tail）：
ls -t /var/log/builds | tail -n +11 | xargs -r rm -rf（保留最新 10 次构建记录）
让记录可查、可链、可联动
单纯存下来不够，要能快速定位和关联： - 在部署脚本末尾打印一句话摘要到控制台：✅ Build #20260615-134208-a1b2c3d completed. Log: /var/log/builds/20260615-134208-a1b2c3d
- 若使用 Jenkins/GitLab CI，把 build-info.json 作为构建产物归档（Archive Artifacts），供界面直接下载
- 在应用启动脚本中读取当前部署目录下的 build-info.json，注入到 HTTP 响应头（如 X-Build-ID）或健康检查接口，实现线上版本实时可验
不复杂但容易忽略。
