Pipe · GitHub Actions 工作流架构

你在解决什么问题

GitHub Actions 工作流一多，常见问题不是「能不能跑」，而是权限过大、第三方 Action 未 pin 到提交 SHA、缓存与分支保护不一致，以及 PR CI 拖太久。把 YAML 当随手脚本写，很容易在复刻 PR 或供应链环节踩坑。

技能如何工作

Pipe 的定位是 GitHub Actions 工作流架构师：每次会话只处理一个工作流、一条流水线、一项安全配置或一次 PR 自动化变更，避免在一次对话里堆满无关改动。

它用一套可执行的工程契约约束设计：

• 工作流按生产代码对待；默认把 GITHUB_TOKEN 设为只读
• 第三方 Action 固定到完整 commit SHA，并用 dependencies 做确定性锁定
• 构建来源走 Sigstore 产物证明；云侧认证优先 OIDC，并启用 Actions Data Stream 做 CI/CD 可观测性
• 绝不在特权上下文中信任复刻（fork）代码
• 性能目标明确：PR CI 尽量 ≤10 分钟，完整流水线 ≤30 分钟；可复用工作流/复合操作遵循「三次法则」再抽象

设计流程固定为 R → O → U → T → E：

| 阶段 | 含义 |
|------|------|
| R | Recon：梳理现有工作流、触发图、信任边界、缓存形态、分支保护与 Action 依赖树 |
| O | Orchestrate：选定事件、依赖图、权限、缓存、运行器组合与出口策略 |
| U | Unify：仅在 ≥3 处重复且证据充分时抽取 reusable workflow 或 composite action |
| T | Test：用 actionlint、act、workflow_dispatch 验证 |
| E | Evolve：收紧安全、压成本、记录残余风险 |

按场景可选用不同「配方」子命令，例如 workflow（新工作流）、reusable、security、pr-automation、matrix、cache、secret（OIDC 与密钥架构）等；各配方会指向对应 reference 文档作为先读材料。

适用边界

• 单会话单主题：不适合在一次对话里同时改多条无关流水线或大规模 monorepo 全量重构。
• 配方有前置阅读：复杂主题（触发器、可复用工作流、矩阵、缓存、密钥）需要按 reference 对齐约束，否则容易漏掉权限或 pin 策略。
• 验证依赖本地/CI 环境：act 与真实 Runner 行为、OIDC 联邦配置仍要以你的仓库与云账号为准，技能输出的是架构与 YAML 方向，不能替代你在目标环境中的实测。