⚙️ GitHub Actions 生成器

选择工作流类型和触发器即可生成可直接放入 .github/workflows/ 的 YAML。支持 Node.js / Python / PHP / Go / Docker / Pages / Vercel / Netlify / Release / Cron / Lint。

完全免费无需注册浏览器内完成 5 种语言深色模式

🔒 关于隐私

・YAML 完全在您的浏览器内生成
・您输入的数据绝不会发送到任何服务器
・无存储日志、无数据库
・无需注册、登录或付款

工作流类型

文件名 (.github/workflows/)

触发器

push pull_request schedule workflow_dispatch

分支

Cron 表达式

操作系统

生成的 YAML

(请点击上方"生成 YAML"按钮)

📖 常见的坑

选择工作流类型（Node / Python / PHP / Go / Docker / Pages / Vercel / Netlify / Release / Cron / Lint）与触发条件，即可生成可直接放进 .github/workflows/ 的 YAML。处理全部在浏览器内完成，分支名与版本号不会被传输。生成的是语法上正确的工作流，而不是能在你的项目里跑通的工作流——安装依赖也好、运行测试也好，实际命令因仓库而异。而在 CI 上真正让人吃苦头的，不是 YAML 格式，而是「权限」与「时间」。下面讲的就是这些。

情形	会发生什么	怎么处理
来自 fork 的 PR 拿不到 secrets	由 `pull_request` 触发的工作流，在 PR 来自 fork 时，`GITHUB_TOKEN` 会变为只读，仓库的 secrets 也不会下发。这是有意为之的安全设计——否则任何人只要提一个 PR，就能让你的机密自己打印出来。结果就是，包含部署或覆盖率上传的工作流，在来自 fork 的 PR 上必定失败。这里有一种广为人知的危险绕法：改用 `pull_request_target` 确实能拿到 secrets，但该触发器以基础分支的权限运行，因此若在其中 `actions/checkout` 并执行 PR 的代码，就等于让外部人员写的代码握着你的 secrets 运行——实质上就是仓库被接管。	请把工作流拆成两个。测试与 lint 放在 `pull_request`（不需要 secrets），部署放在 `push` 到 main 或 `release`。这样来自 fork 的 PR 也能正常通过 CI，而 secrets 也不存在外泄的通路。如果确实要用 `pull_request_target`，请绝对不要 checkout PR 的代码——把它限制在打标签、发评论这类不执行代码的用途上。同时，请在每个工作流的开头显式写出 `permissions:`——仅仅写上 `permissions: {contents: read}`，就能让该工作流的 `GITHUB_TOKEN` 失去写权限。之后再按 job 逐一补上真正需要的权限，这才是正确的顺序。
用标签引用第三方 action	`uses: some/action@v1` 里的 `v1` 是分支或标签，也就是可移动的引用——只要 action 的作者（或夺取了那个账号的人）替换了内容，你的 CI 下一次运行的就是另一份代码。而那份代码能访问 `GITHUB_TOKEN` 以及你传给该 job 的所有 secrets。这并非纸上谈兵：热门 action 被入侵并用于收集机密的事件真实发生过。*官方的 `actions/` 姑且不论，随手用 `@main` 引用一个 star 不多的顺手小 action，与把仓库的写权限交给陌生人并无实质差别。**	第三方 action 请固定到 commit SHA——写成 `uses: some/action@a1b2c3d4...`。SHA 无法被改写，因此下一次运行什么是确定的。更新交给 Dependabot（在 `.github/dependabot.yml` 里加上 `package-ecosystem: "github-actions"`，它就会自动提交升级 SHA 的 PR）——固定与更新可以并存。从源头减少 action 数量同样有效：如果某个 action 只是复制一个文件，在 `run:` 里写 `cp` 就少了一个依赖。另外，secrets 请按 job 最小化下发——把它们作为环境变量放在整个工作流层级，里面所有 action 都能读到。
cron 不会准点运行，且 60 天后会停	`schedule` 触发器除了写法之外还有三个坑。时间一律是 UTC，不是你所在的时区——*`0 3 * ` 指的是「UTC 凌晨 3 点」。执行并不准点——繁忙时段会延迟数分钟到数十分钟，负载高时甚至可能整次跳过。每小时的整点是最拥挤的时段，因此光是避开整点就能稳定不少。而最让人意外的是第三点：对于连续 60 天没有提交的仓库，GitHub 会自动停用其计划工作流——虽然会发邮件，但一旦漏看，「回过神来发现好几个月都没跑过」是再平常不过的结局*。	cron 表达式请按 UTC 编写，并从整点错开几分钟——写 `17 3 * * ` 而不是 `0 3 * `。并且请务必同时写上 `workflow_dispatch`——能手动触发，才谈得上验证与重跑（「不等到计划时间就无法试」这种状态本身就是事故之源）。对自动停用的防御，是让自己「能够察觉」：在 job 末尾向外部系统发送成功通知，从而让「通知中断」这件事可被发现——只对失败告警，是检测不出「任务不再运行」的。若需要精确的时刻或较高的可靠性，请使用专门的调度器，而不是 GitHub Actions 的 cron。*

缓存的键请与锁文件一起构造。如果 actions/setup-node 的 cache: npm 或 actions/cache 的 key 不包含锁文件的哈希，那么即使更新了依赖，恢复的仍是旧缓存——于是出现本地已经修好、唯独 CI 用着过期依赖失败这种难以定位的状况。请把 hashFiles('**/package-lock.json') 加进键里。另外，缓存是跨分支共享的——坏掉的缓存会传染给其他分支，可疑时改个键名重建更快。还有一点：注意不要把机密打进日志。GitHub 会自动遮蔽已登记的 secrets，但经过加工的值（做了 Base64、嵌进 JSON、只截取了一部分）不会被遮蔽。一旦启用 set -x 或调试输出，整条命令行都会被记录——而在公开仓库中，Actions 的日志任何人都能读。

📖 使用方法

1

选择工作流类型

从 Node.js / Python / PHP / Go / Docker / Pages 等中选择。
2

设置触发器和分支

启用 push / pull_request / schedule / 手动触发,并输入分支或 cron 表达式。
3

生成 YAML 并提交

点击生成 YAML,复制或下载,放入 .github/workflows/ 后推送。

❓ 常见问题

生成的 secrets 如何配置?

在仓库 Settings → Secrets and variables → Actions 中添加同名 secret。

使用哪些 actions 版本?

使用 actions/checkout@v4 与 actions/setup-* v5 等稳定版本。

可用于自托管 runner 吗?

可以。把生成的 runs-on 改为 self-hosted 即可。

🔗 相关工具

🐛 此工具出现问题了吗？

免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。