Buildkite 动态流水线架构师

要解决什么问题

在 Buildkite 里维护过大型流水线的人，大概都有类似经历：pipeline.yml 里躺着几十个步骤，其中相当一部分在本次小改动里根本用不上。静态定义的流水线只能「全量跑」或「手动注释」，要么浪费 CI 时间，要么依赖人记得去改配置——而人总会忘。

当代码库按模块拆分、多应用共存时，问题会更突出：一次只改了 services/payment 下的三个文件，流水线却照常拉起前端构建、Go 服务测试、容器镜像推送等全部阶段。

它如何工作

这个技能的思路，是把「跑哪些步骤」从写死的配置文件，变成由代码变更推导出的结果。

• 变更感知：通过 git diff 对比本次提交涉及的文件路径，得到变更范围。
• 条件步骤生成：依据变更路径与预设规则的匹配结果，决定哪些步骤进入本次流水线；未触碰相关模块时，对应步骤直接省略。
• 动态构建：借助 Buildkite REST API 与 pipeline upload 机制，在运行时组装出实际要执行的流水线结构，而不是依赖仓库里那份静态 YAML。

整体流程大致是：读取变更 → 匹配规则 → 生成步骤集合 → 上传动态流水线。

适用边界

• 规则匹配的精度取决于路径划分粒度。目录结构扁平时效果好；存在大量交叉依赖的 monorepo，需要更细致的规则设计。
• 变更检测基于 git diff，因此对「无代码变更但仍需触发」的场景（如纯配置中心更新、手动重新部署）并不适用。
• 自动生成流水线属于敏感操作，接入生产流程前，建议先在测试 pipeline 上验证生成结果是否符合预期。