PROSAGA码农传奇-Teambition-GitHub Actions与其他CI工具（例如Jenkins）有什么区别？

我已经全职使用GitHub行动几个月了。

还很早（2019年6月），但这是我的清单：

优点：
GitHub动作只是连续的docker运行。非常容易推理和调试。复制基于容器的Travis的构建环境是可能的，但是更加困难。在GitHub上，这一切都遥不可及docker build docker run。
个人行动的工作流程默认隔离。您可以使用完全不同的计算环境进行编译和测试。Travis CI（我认为其他“传统” CI）将在同一计算环境中运行所有“阶段”（〜动作）。同样，GitHub动作更易于推理和调试。
该main.workflow规范（HCL中的一个子集，其实只是一个向无环图）是开源的。整个过程还是围绕Docker的一个非常薄的包装，因此可以说平台锁定是最小的。
有已经 GitHub的动作，如开放源代码重新实现的行为进行本地测试。
您可以立即使用具有（有些限制）身份验证的GitHub API访问权限。
有可能是一个充满活力的社区（市场？），人们可以分享的行为。例如，我正在重用由不同生态系统中的不同人构建的部署操作。
main.workflows的有向无环图（DAG）和可视化编辑器也许是对CI / CD尤其是工作流进行建模的好方法。需要一些时间来适应，但是概括性很好。
GitHub的动作可以做的不只是CI！您基本上就可以将整个API作为输入和输出。
缺点：
GitHub动作（仍然？）有时在这一点上有令人惊讶的基础限制（2019年6月）。

没有本地缓存。您将获得图像和图层缓存（这很复杂），但仅此而已。对于构建文物，您必须滚动自己的缓存（通过AWS，Azure等...），这可能需要很多工作。（您可以在此处看到一个骇客的设置。
令人惊讶的是，不支持forks的拉取请求。从安全的角度来看，这又有点复杂，并且可以理解，但是当前不可能对分叉PR（基础）的接收存储库的秘密运行操作a）和/或b）对可能的合并结果进行操作分叉PR（这是travis的功能）。对于涉及派生的工作流，这使得GitHub动作在很大程度上不能用作CI / CD工具。
单一平台，就是您可以在docker中运行的任何东西，因此有一些Linux发行版。这似乎不太可能改变，但可能是可以接受的限制。您始终可以添加操作以调用其他跨平台的CI / CD服务。
该文档仍然很少。最佳做法或脚手架的方式不多。
（至少在市场上）已发布的GitHub操作的质量和广度仍然很低/有限。我们将看看这是否成功。
没有很好的方法对单元进行测试。（我一起砍了一些东西，但是我不太确定）。