对于许多需要在新环境中快速启动和运行CI或CD的团队来说，GitHub Actions已经成为了默认选择。此外，它还能承载更复杂的工作流程，并且能够调用其他复合任务中的任务。尽管GitHub应用市场中的生态在不断发展，我们仍然强烈建议谨慎授予第三方GitHub Actions权限访问您的构建流水线。我们建议您遵循GitHub有关安全强化的建议，避免以不安全的方式共享机密信息。 但是，直接在托管源代码的GitHub上创建构建工作流的便利性，再加上能使用像act等开源工具在本地运行GitHub Actions，让其成为简化团队设置和新成员上手流程的一个引人注目的选项。
GitHub Actions 的使用量在去年大幅增长。之前的使用经历已经证明它可以处理更复杂的工作流程，并在复合操作中调用其他操作。但是，它仍存在一些缺点，例如无法重新触发工作流的单个作业。尽管 GitHub Marketplace 中的生态系统有其明显的优势，但让作为第三方的 GitHub Actions 访问你的构建流水线可能会以不安全的方式共享机密信息（我们建议遵循 GitHub 关于安全强化的建议）。尽管如此，GitHub Actions 以其在 GitHub 中的源代码旁直接创建构建工作流的便利性，结合使用 act 等开源工具在本地运行的能力，是一个利于团队刚开始开展工作以及新人上手的强有力选项。
虽然曾在技术雷达中提出慎用的建议，但我们依然看到了用户对于GitHub Actions的持续热情。尽管如此，之前的建议依然有效——对于复杂工作流来说，GitHub Actions还不算成熟的CI/CD工具。例如，它不能重新触发工作流中单独的一个job，不能在composite action中调用其他的action，也不支持共享库。另外，虽然GitHub Marketplace 生态圈具备显著的优势，但让第三方的Github Actions访问自己的构建流水线，会带来以不安全的方式共享机密的风险（我们建议遵循GitHub 的安全加固建议）。尽管有种种顾虑，但在GitHub源代码旁直接创建构建工作流的便利性，对很多团队还是有着不小的吸引力。另外，还可以使用act 在本地运行Github Actions。和以前一样，我们建议审慎地权衡Github Actions的优缺点。但我们的很多团队还是非常喜欢它的简单性。
在我们的工具箱中，CI服务器与构建工具最为古老，使用也最广泛。其工作范围包括简单的云托管服务，一直到复杂的、由代码定义的、支持大型构建机群的流水线服务。鉴于市面上已经有大量的同类产品，当另一个用于管理构建与集成工作流 GitHub Actions 出现时，基于经验我们起初抱有怀疑的态度。但是 GitHub Actions 为开发者提供了小步启动并可以轻松自定义的行为，并逐渐成为小型项目的默认选项。将构建工具直接集成到源代码库实在很方便，因此社区也很活跃。大量用户贡献了工具以及工作流，便于快速上手。工具供应商也可以通过 GitHub Marketplace 提供服务。但是，我们仍然建议你保持谨慎。因为尽管代码和 Git 历史记录可以导出到其他服务器中，但是基于 GitHub Actions 的开发工作流程却不能。另外，你也需要自行判断何时项目会变得足够大或足够复杂，而需要使用有独立支持的流水线工具。但对于初创而需要快速运行的、较小的项目，仍然值得考虑 GitHub Actions 及其不断发展的生态系统。
