GitHub Actions 是个问题
许多开发者称赞 GitHub Actions 在多个平台上提供了免费、方便的 CI/CD，但也越来越批评它的工作流不透明、反馈循环慢、YAML 复杂以及供应商锁定。评论者认为，核心构建和部署逻辑应该放在普通脚本中，这些脚本可以在本地或任何 CI 系统上运行，而 Actions 只用于轻量编排。文中还提到了多种替代方案和变通办法——从 Dagger、Earthly、Garden、`act` 到自托管 runner 和通用工作流引擎——都旨在重新获得流水线的可移植性、可测试性和控制权。
GitHub Actions 的感知问题
- YAML 工作流变得复杂、难以调试，而且不容易在本地测试。
- 对第三方 actions 的强依赖使行为不透明，并增加了供应商锁定。
- 术语令人困惑（actions 与 workflows），runner 的实现也被认为很繁琐，并且有关于奇怪行为和退出码的报告。
- 反馈循环很慢：为了迭代流水线逻辑，需要提交和远程运行，这一点被广泛讨厌。
- 有些人认为 Actions “够用”，但在概念清晰度上不如 GitLab CI 这类更简单的系统。
变通办法和推荐实践
- 保持 YAML“薄”：主要用于触发和编排；把真正的逻辑放到脚本、Make/just 目标、Magefiles、Bazel 等里。
- 确保所有 CI 步骤都能用与 CI 相同的命令在本地运行。
- 相比重型可复用 actions，更倾向于本地脚本和容器；有人会避免使用除基础设置 actions 之外的所有 actions。
- 将 Docker 镜像或 devcontainer 镜像作为本地和 CI 运行的标准环境。
- 通过共享脚本或编译成 CI YAML 的 DSL 集中管理公共逻辑；把 CI 视为粘合层。
本地执行和工具缺口
- 对第一方本地运行 GHA 的方式需求很强；当前自托管 runner 仍然需要提交和远程执行。
act及相关模拟器能帮助一些工作流，但被描述为不完整、脆弱，并且在复杂流水线下难以调试。- 反向 shell/调试 actions（例如 tmate）因可在实际 runner 上排查问题而受到赞赏。
供应商锁定和平台担忧
- Actions 的生态系统以及免费/低价的托管 runner（尤其是 Windows/macOS）被视为强大的锁定机制。
- 有人认为 GitHub 对 CI 的变现会降低提供完全本地、免费的 runner 的动机。
- 也有人强调 GitHub 更广泛的功能集和网络效应才是主要“黏性”来源。
替代性的 CI/工作流方法
- 多个项目致力于 CI 无关或“代码即流水线”方案（Dagger、Earthly、Garden、Windmill、Cirrus CLI、Cicada）。
- Jenkins 的 Groovy DSL 和共享库被认为比原始 YAML 更好的抽象模型。
- 构建通用工作流/CI 引擎的尝试会遇到抽象泄漏、环境差异和高迁移成本。
对 CI/CD 复杂性的更广泛反思
- 许多人认为 CI 流水线是不断重复发明的过度复杂工作流引擎。
- 大家普遍认同：部署应该是可审计、可脚本化的，并且不应完全绑定到某一个 CI 提供商。