Buildkite 动态流水线代理

解决什么问题

Buildkite 的经典用法是把流水线写成一份 YAML 提交进仓库，agent 拉取后按声明执行。这个模型在「改配置就提 PR」的场景下很顺手，但当流水线本身的形状取决于运行时条件时就会别扭：分支名决定该跑哪组测试、上游产物版本决定后续 stage 的参数、刚扩容出来的临时机器池需要立刻被用上。把每种组合都写成一份静态文件，结果往往是大量近似重复的 YAML 和持续的维护成本。

它是怎么工作的

这个技能绕过静态声明路径，直接对接 Buildkite REST API，并配合 pipeline upload 命令在运行期把流水线定义推给 Buildkite。典型链路是：

• 依据上下文（分支、PR 元数据、外部服务返回值）在运行期拼装出一份流水线定义；
• 通过 REST API 创建 pipeline，再用 pipeline upload 提交步骤与配置；
• 借助 queue label 把作业绑定到特定类型的 agent，让机器选择发生在调度侧，而不是靠 agent 自行猜测；
• 为不稳定测试配置自动重试策略，让偶发失败不必阻塞整条流水线。

适用边界与注意点

• 当前资料没有提供可自动提取的源码级安装或使用说明，接入前需要自行查阅上游项目，确认调用方式与版本兼容性。
• 进入生产环境前，先核对 REST API 的权限范围与 pipeline upload 的令牌管理方式，不要在敏感流程里直接复用现成凭据。
• 重试策略要区分「真正的偶发失败」和「环境性必现失败」，否则重试只会把问题推迟到更难定位的时刻。
• 接口细节以官方文档为准：https://buildkite.com/docs