GitHub Actions是一种自动化的CI/CD平台，它与GitHub集成，在创建无缝的、多功能的CI/CD流水线方面非常有用。下面是它的工作方式。
GitHub Actions是内置于GitHub中的一个平台，用于自动化软件构建、测试和部署。GitHub是一个由Microsoft拥有的托管服务，用于使用Git，一个由Linus Torvalds开发的开源版本控制和协作程序进行软件开发。Git和GitHub已经被许多程序员和软件店用作他们的开发实践的基础，包括自动化的持续集成和持续交付流水线，用于项目的构建、测试和部署周期。GitHub Actions为GitHub用户提供了一个GitHub所谓的“因果关系API”。您可以使用这个平台根据各种触发器自动化各种行为。
GitHub在2018年推出了GitHub Actions。由于GitHub的开放性，它不是你可以用来实现基于GitHub项目的CI/CD自动化的唯一工具。在某些情况下，其他工具，如Azure Pipelines和Jenkins，可能更为优选。但是，由于GitHub Actions与整个GitHub平台集成在一起，用户不需要担心底层基础设施。 它的整体工作流也是以GitHub为中心设计的，这将使它成为许多人的理想选择。
GitHub Actions的工作方式如下：
理解GitHub Actions如何工作的最佳方式之一是考虑描述其各个组件的术语。我们将从名称“GitHub Actions”开始。我们遵循GitHub的规定，将其作为单数名词（“GitHub Actions是......”），将平台作为整体名称。还有一个名为“Action”的平台组件（小写字母“a”），我们很快就会讨论。
现在，让我们看看平台的一些组件：
- 事件: 事件是推动GitHub Actions自动化流水线的原动力。这个事件可能是库内发生的具体事件，例如拉取请求或提交被推送，也可能是计划触发器、对REST API的帖子，甚至仅仅是手动命令等。
- 工作流程: 任何这些事件都可以触发工作流程，这是您使用GitHub Actions编制的自动化过程的总体术语：例如，当新版本准备好部署时，您可以使用工作流程来部署您的应用程序，或者在某个人打开一个新问题时添加适当的标签。 工作流程在保存在存储库的
.github/workflows目录中的YAML文件中定义：请查看GitHub的文档，了解语法。这个文件将定义可以触发工作流程的事件，以及您想要工作流程完成的实际任务。 - 工作: 您想让工作流程完成的任务被分成一个或多个工作。每个工作是您定义顺序发生的一组步骤；您的工作流程可以由多个并行运行的工作组成，或者按照预定义的顺序彼此跟随，或者两者的组合。您也可以在工作之间创建依赖关系。例如，您可能会有多个正在不同芯片架构上并行运行的构建工作。完成所有这些工作后，另一个工作将打包构建。
- 行动: 工作中的各个步骤可能由一个简单的shell脚本组成，但如果您需要更复杂的内容，还可以使用Action（请注意小写的a）。行动由您编写的与GitHub存储库交互的代码组成；您可以使用GitHub的API，也可以使用任何可用的第三方API。行动执行的任务的范围可以从当代码准备好生产时部署它到向值班程序员发送SMS警报以处理紧急问题。行动可以编写为在Docker容器内运行，但这不是必需的。
行动的关键点之一是它们是可重用的。虽然shell脚本调用可以简单地包含在定义工作流程的YAML文件中，但行动是独立的应用程序，被引用在YAML文件中，并可以由您组织中多个工作流复用。这种可重用性是行动最强大的方面之一，也是为什么它们是GitHub Actions整个命名的重要组成部分。您也可以利用GitHub Actions市场中广泛的第三方创建的操作的各种操作；尽管名称是这样，但这些操作是免费使用的，并且大多是开源的。您也可以将自己的操作贡献给市场。
- 运行: 运行是作业运行的服务器。工作流程中的每个作业都有自己的运行程序；正如您可能预期的那样，这些通常是虚拟机，并且是为您的工作自动配置的。GitHub为此目的提供托管虚拟机——运行Ubuntu Linux、Microsoft Windows或macOS——但如果您需要您的工作运行在特定的硬件配置或操作系统上，您可以自行托管运行程序。
GitHub Actions的示例
Github文档包括一些示例，以帮助您了解GitHub Actions的工作方式。首先，您可以在runner上[测试代码]（docs.github.com/en/actions/… Actions]（docs.github.com/en/actions/…
更进一步的示例，对于探索GitHub Actions的强大作用可能非常有用，涉及到GitHub所谓的“矩阵策略”。在这种类型的工作流中，您将在定义工作时使用变量，以便根据变量的值创建基于变量的多个作业运行。正如GitHub举例所示，这是自动将代码测试与不同的语言或操作系统版本进行对比的好方法；您可以更改变量的值以选择新的测试环境。
Fireship.io有更多有用的GitHub Actions示例可供参考，包括演示如何在创建新版本时将软件包发布到NPM;如何自动发送电子邮件、Slack或Discord消息更新用户的工作进度;或如何在特定时间或特定间隔安排后台作业。
GitHub Actions的安全最佳实践
如果您正在GitHub存储库中运行GitHub Actions上的代码，则几乎可以确定您正在处理分布式代码库，这带来了安全性上的复杂性。GitHub建议采用以下最佳实践，以确保您的工作流程是安全的：
- 对于敏感数据，请使用密码等硬编码到工作流程定义中。GitHub允许您将这种信息保存为加密的机密信息；实际上，如果您使用机密信息来生成应该受到安全保护的其他信息，您也可以将该值注册为机密信息。
- 保留workflow文件的控制权：如果攻击者设法更改workflow定义，只需运行一个作业，您就可以打开系统以进行渗透或攻击。 使用GitHub代码拥有者功能，以规范访问保存YAML文件的目录。
- 防止脚本注入：像任何可以接受输入的应用程序一样，如果攻击者设法传递可执行代码，操作也可能被欺骗为恶意。 您应该对GitHub Actions应用相同的防御性编码技术，这些编码技术适用于任何其他可能敏感的代码。
- 谨慎使用第三方代码：除了GitHub Actions市场之外，还有许多其他地方的社区成员共享操作和工作流程代码。这些资源可能会有所帮助，但您不应该在不考虑的情况下将第三方代码插入代码库中。请确保对这些模块进行与您将投入生产的任何其他代码相同的安全审查。
有关更深入的安全信息，请查看GitHub的[GitHub Actions安全强化指南]（docs.github.com/en/actions/…
将GitHub Actions与其他平台集成
由于GitHub是一个相对开放的平台，而GitHub Actions工作流程是通过声明性YAML描述的，因此您可以将GitHub Actions代码与其他平台进行集成：
-
AWS：您可以使用包装器将操作转换为类似的CodeCatalyst操作，从而在CodeCatalyst上（AWS的托管软件开发服务）重用您的操作。
-
Azue：Microsoft（它是GitHub的终极母公司，尽管它采取相当的较为慎重的态度）使得编写GitHub Actions工作流程[部署代码]（learn.microsoft.com/en-us/azure… App Service托管平台成为可能。
-
Visual Studio：说到Microsoft，该公司闻名的Visual Studio IDE有一个[扩展程序]（marketplace.visualstudio.com/items?itemN… Actions工作流程而不离开编辑器。
-
Google Cloud:Google已经提供了[许多操作]（github.com/google-gith…
我需要为GitHub Actions付费吗？
如果您的作业在公共存储库中的标准GitHub托管运行程序上执行，或者如果您自己主机运行您的运行程序，则GitHub Actions是免费的。如果您正在使用私有存储库，您可以免费获得一定数量的存储和计算时间，但一旦超过这些限制，您必须付费。同时，还有关于使用GitHub托管运行程序的并发作业数量、每小时的API请求数和工作流程运行时间的总体限制。请参阅[GitHub文档]，了解更多详情。
GitHub Actions的替代品
市场上有其他工具可以自动化CI/CD过程，因此占据了与GitHub Actions的大部分空间相同的位置。也许最为突出和成熟的之一是Jenkins，这是一种开源提供，可以追溯到2004年。Jenkins可以通过插件与GitHub存储库一起使用——以及任何其他环境中的代码——并且通常非常灵活，虽然相对于GitHub Actions来说学习曲线可能较陡。
总的来说，GitHub Actions最大的优点是与GitHub的紧密集成。其他托管服务有自己的类似程序，例如GitLab有GitLab CI，还有AWS CodeCatalyst操作。如果您使用GitHub并且没有投资于像Jenkins这样的跨平台工具中，GitHub Actions是您自动化CI/CD需求的逻辑选择。
