buildtime

buildtime

你的构建越来越慢，但到底是哪个步骤拖了后腿？ buildtime 会分析一组 CI 运行记录——各步骤的耗时，以及已知的缓存命中情况——并用数据指出瓶颈：

• 各步骤统计信息 — 对每个不同的步骤名称，统计包含该步骤的运行次数、总耗时、平均耗时、最长耗时，以及该步骤占总耗时的比例；按耗时从高到低排序（耗时相同则按名称排序）
• 最慢步骤 — 排名中的第一项
• 趋势 — 按给定顺序排列运行记录，并分为前半部分和后半部分（奇数条记录时，中间那条归入前半部分）；分别计算每部分的平均运行总耗时，以及两者之间的百分比变化；少于两条运行记录时为 null，前半部分的平均耗时为零时，百分比变化为 null
• 缓存相关性 — 某条运行记录只要至少有一个步骤报告缓存命中，就计为“命中缓存”；buildtime 会报告两组的数量和各组的平均运行总耗时（空组为 null，绝不会填为零）
• 标记最慢步骤 — 传入耗时阈值时，列出平均耗时达到或超过该阈值的步骤，并按耗时从高到低排序

所有浮点数均四舍五入到小数点后四位。计算过程纯粹且在本地执行：不会联网，不需要配置，也不会读取你所传入运行记录以外的任何文件。无效输入——缺少运行记录、步骤缺少耗时或耗时为负——都会报错并指出出错路径，且不会生成不完整的分析结果。

CLI

npx @reneturcios/buildtime analyze --runs runs.json
npx @reneturcios/buildtime --version

runs.json 包含完整的参数对象：

{
  "runs": [
    {
      "run_id": "run-101",
      "conclusion": "success",
      "steps": [
        { "name": "compile", "duration_seconds": 42.5, "cache_hit": true },
        { "name": "test", "duration_seconds": 87 }
      ]
    }
  ],
  "slow_threshold_seconds": 60
}

conclusion 和 cache_hit 对每条运行记录／每个步骤而言都是可选的，slow_threshold_seconds 整体而言是可选的。分析结果将以 JSON 格式输出。

退出代码：成功时为 0；运行时错误（包括无法读取或内容无效的运行记录文件，或输入无效）时为 1；用法错误时为 2。

MCP 服务

npx -y @reneturcios/buildtime mcp

MCP 客户端配置：

{
  "mcpServers": {
    "buildtime": {
      "command": "npx",
      "args": ["-y", "@reneturcios/buildtime", "mcp"]
    }
  }
}

工具

• analyze_build_times — 分析多次 CI 运行中的构建瓶颈。

  • runs（数组，必填，至少一条）— 运行记录，格式为 {run_id, conclusion?, steps}；其中每个步骤的格式为 {name, duration_seconds, cache_hit?}
  • slow_threshold_seconds（数字，可选，>= 0）— 标记平均耗时达到此阈值的步骤

  返回 {run_count, grand_total_seconds, step_stats, slowest_step, trend, cache, flagged_slowest}。

Docker

docker run -i ghcr.io/cloudcorprecords/buildtime
docker run --rm -v "$PWD:/w" ghcr.io/cloudcorprecords/buildtime analyze --runs /w/runs.json

开发

npm install
npm run build   # tsc -> dist/
npm test        # tsx --test test/*.test.ts (pure local, no network)
npm run dev     # run the CLI from source

许可证

MIT — 版权所有 (c) 2026 Rene Turcios