GitHub Actions CI speed guide from Mole, Kaku and Pake maintainer
The prompt turns CI optimisation into a repeatable agent task: paste it into Claude or another coding agent and get a before-and-after timing report. The trap to watch is that skipping required checks on docs-only PRs can block merges unless branch protection is adjusted. Developers running Actions on free plans, especially with macOS runners capped at five concurrent jobs, get the most direct benefit.
Tw93, the developer behind Mole, Kaku and Pake, spent an afternoon optimising the GitHub Actions CI pipelines for all three projects and shared a copy-paste prompt for AI agents. The method starts by using the gh CLI to pull the last 50 workflow runs and break each job into queuing, setup and test phases. It covers cancel-in-progress for superseded PR runs, paths filters for docs-only commits, built-in caching via setup-node, setup-go and Swatinem/rust-cache, precompiled binaries instead of go install or cargo install, and parallelising independent jobs. It also flags constraints like the 10 GB per-repo cache limit and the 5 concurrent macOS runner cap on free accounts.
有了 AI 以后写代码速度快了非常多，但是校验的速度其实还是不快的，特别是在 GitHub 上跑 Actions CI 的速度，下午花了一些时间对 Mole、Kaku、Pake 的 CI 全部彻底优化了一下，效果很不错，分享给大伙。 你可以这样直接 Copy 下面给到你的 Agent，我们来看看可以帮你节约多少时间。 帮我把这个仓库的 GitHub Actions 提速，在不减少必要的测试项以及功能校验下，最大幅度减少耗时。 1. 先使用 gh 拉最近 50 次的运行情况，把每一个 job 拆成排队、准备、真正跑测试的 3 个时间段，去看规律，可能很多时候慢的是准备的阶段，不是测试本身。 2. 同一个 PR 连着推好几次时，只跑最新的那次，旧的直接取消掉，用 cancel-in-progress 去实现。不过 main 分支不要这么做，需要确保发版 main 上的每一个提交都完整跑过一遍。 3. 只改 README 和文档的这种提交不要触发跑 CI，可以用 paths 过滤掉，另外被跳过的必需检查会一直卡住 PR 合不进去，这个要提前注意一下。 4. 优先用 setup 类 action 自带的缓存，setup-node 打开 cache，setup-go 默认就开，Rust 用 Swatinem/rust-cache，注意每个仓库缓存只有 10 GB，用不上的就不要放到这里面去。 5. 本地连着构建两次，第二次应该几乎不花时间，假如有多余的花时间的地方，一定是哪些写得有问题，比如 Dockerfile 装依赖前先 COPY 了整个仓库，或者构建脚本盯着一个不存在的文件，类似的问题记得检查。 6. 工具直接下载预编译好的，不要用 go install、cargo install 现场安装编译，这里会很费时间。 7. 不互相依赖的 job 并行跑，删掉不传数据的 needs，最长的那套测试拆到多台机器上去跑。 8. 免费账号的 macOS 最多同时跑 5 个，所有 workflow 共用，格式化、lint、依赖审计这些不挑系统的都移到 Ubuntu 去跑更好。 9. 做过的事情就不要做重复了，以及不要多此一举做事情，比如别的 job 跑过的检查就不要套重复再跑，比如只构建前端的 job 就不要多此一举去拉整个 Rust 缓存。 10. 改完去 push 那个上面测试运行效果，看运行的时间，发现规律，再次查漏补缺来优化一遍，做到最好，最后给到我优化前后的对比。 💬 80 🔄 46 ❤️ 734 👀 54140 📊 286 ⚡
