nektos/act

act 是一个 Go 命令行工具，让你在本机执行仓库里的 .github/workflows/ 文件，而不必先提交、推送再等 GitHub CI。它面向需要反复调试工作流定义、并且愿意在本地运行容器的人。

实际会改变什么

要测试工作流改动时，不再靠提交和推送，而是直接对本地工作流文件运行 act。README 描述的过程是：读取工作流，确定需要执行哪些 action，通过 Docker API 拉取或构建所需镜像，根据工作流中声明的依赖决定执行顺序，然后为每个 action 运行一个容器；环境变量和文件系统也按 GitHub 托管 runner 的行为进行配置（README）。

README 还给出第二种用法：把已有的 GitHub Actions 当作本地任务运行器，替代 Makefile（README）。第三方 VS Code 扩展 GitHub Local Actions 可以在编辑器内调用 act（扩展文档）。

依赖条件

文档描述的主流程都通过 Docker API 运行；README 中运行测试同样需要 Docker，只有 make test-fast 不需要（README）。从源码构建时，README 要求安装 go.mod 中指定版本的 Go（目前为 1.26.0），并执行 make install（构建说明）。完整用户文档在项目站点（act 用户指南）。

本地运行可能和 CI 不一致

本地环境不是 GitHub 托管 runner。2025 年一位 Hacker News 评论者表示，在 Apple 芯片上因平台差异、自定义 runner 镜像等问题的叠加，即使试了体积很大的 catthehacker 镜像，也没能让流程跑起来（HN 评论，2025-05-16）；另一位评论者说在 Linux 上也遇到类似的环境问题（HN 回复，2025-05-19）。这些是个人经历，不构成兼容性清单，但说明了一个实际限制：依赖 GitHub 专属 runner 镜像或特殊环境的步骤，本地未必表现一致。

较早的讨论中反复提到一个行为：不带参数运行 act 会并行执行仓库里的所有工作流，而不是显示用法（HN 评论，2022-11-26）。首次运行前值得留意这个默认行为。

项目采用 MIT 许可证，并有社区讨论区提供支持（代码仓库、讨论区）。