GitHub Actions 实战配方

这个技能解决什么问题

写 GitHub Actions 的人都遇到过这两种情况：要么打开 awesome-actions 列表，面对上千个 action 不知道挑哪个；要么好不容易拼出一条流水线，结果每次提交都跑 20 分钟，还动不动因为网络抖动挂掉。慢的流水线没人愿意等，脆的流水线没人敢信。这个技能把"选型 → 组合 → 调优"压缩成一套可复用的配方，帮你从零散信息里组装出快、稳、可读的 workflow。

核心能力与关键步骤

最小可用的流水线骨架

技能首先给出任何项目都适用的起点：actions/checkout 拉代码 → 对应语言的 setup-* 装环境 → 跑测试 → 缓存依赖。不需要花哨的结构，先把 CI 跑通。

提速三板斧

1. 缓存：用 actions/cache 缓存 node_modules、pip 包、~/.gradle 等依赖目录，避免每次从头安装
2. 矩阵：用 strategy.matrix 一次测试多个 Node/Python/Go 版本或多操作系统，单份配置覆盖多环境
3. 复用：用 workflow_call 把公共步骤抽成可调用的工作流，而不是在每个文件里复制粘贴

常用选型表

技能内置一份场景 → action 映射，涵盖检出代码、装环境、构建容器（docker/build-push-action）、发版（softprops/action-gh-release）、缓存等典型场景，直接给出社区验证过的选项。

安全红线

跨仓库或云平台授权优先用 OIDC 换取临时凭证，而不是把长期密钥硬编码进 secrets。同时明确标注三个高频陷阱：

• pull_request_target 误用会泄露密钥给 fork 仓库
• 每步都 npm install 且不加缓存 → 又慢又容易挂
• action 使用 @master 浮动版本 → 构建不可复现，应锁定 @v4 或具体哈希

适用边界

所有配方以 GitHub 官方文档为准，AI 生成的配置在上线前应人工审查。当自动化流程拥有仓库写权限时，严格遵循最小授权原则，并审查每个第三方 action 的来源——这是安全的最后一道防线，也是这个技能反复强调的底线。