GitHub Actions与其他CI工具（如Jenkins）有什么区别？

Question

GitHub宣布了一项即将发布的功能GitHub Actions。

我对詹金斯（Jenkins）等CI工具对自动构建或测试的好处持肯定态度，GitHub Actions旨在将其用于将来。

在GitHub上拥有存储库并使用外部CI工具具有巨大的好处，即无需重写整个CI流程即可将存储库移至另一个Git存储库平台（甚至本地）。借助GitHub Actions，您或多或少与GitHub生态系统联系在一起。

我认为GitHub的Actions集成在本机环境中会更流畅，但是除此之外还有其他优点或缺点吗？

Answer 1

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

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

好处：

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

缺点：

GitHub动作（仍然？）有时在这一点上有令人惊讶的基础限制（2019年6月）。

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

Answer 2

在 GitHub 上拥有一个存储库并使用外部 CI 工具有一个巨大的好处，即允许将存储库移动到另一个 Git 存储库平台（甚至本地）而无需重写整个 CI 过程。
使用 GitHub Actions，您或多或少会与 GitHub 生态系统联系在一起。

是的，从 2019 年 11 月开始，略有下降：

请参阅Joe Bourne的公告“ GitHub Actions 的自托管运行器现已处于测试阶段”。

您可以拥有自托管的运行器，这意味着：

• 你的环境，你的工具，
• 任何尺寸的机器或配置，
• 安全访问和网络，
• 大工作量支持。

为了支持在您的工作流程中使用自托管运行器，我们扩展了使用runs-on密钥的体验。
在注册您的自托管运行器时，他们每个人都会获得一个只读标签自托管，您可以将其与runs-on.
下面是一个例子：

# Use Any available Self-hosted runners connected to repo
runs-on: self-hosted

请参阅“托管您自己的跑步者”中的文档。