概述
GitHub Actions 是一种持续集成和持续交付 (CI/CD) 平台，可用于自动执行生成、测试和部署管道。 您可以创建工作流程来构建和测试存储库的每个拉取请求，或将合并的拉取请求部署到生产环境。
GitHub Actions 不仅仅是 DevOps，还允许您在存储库中发生其他事件时运行工作流程。 例如，您可以运行工作流程，以便在有人在您的存储库中创建新问题时自动添加相应的标签。
GitHub 提供 Linux、Windows 和 macOS 虚拟机来运行工作流程，或者您可以在自己的数据中心或云基础架构中托管自己的自托管运行器。
有关将 GitHub Actions 引入你的企业的详细信息，请参阅“为企业引入 GitHub Actions”。
GitHub Actions 的组件
可配置 GitHub Actions 工作流，使其在存储库中发生事件（例如打开拉取请求或创建问题）时触发 。 工作流包含一个或多个可按顺序或并行运行的作业。 每个作业都将在其自己的虚拟机运行器中或在容器中运行，并具有一个或多个步骤，用于运行定义的脚本或运行动作。动作是一个可重用的扩展，可简化工作流 。
工作流
工作流是一个可配置的自动化过程，它将运行一个或多个作业。 工作流程由签入到存储库的 YAML 文件定义，并在存储库中的事件触发时运行，也可以手动触发，或按定义的时间表触发。
工作流在仓库的 .github/workflows 目录中定义。 一个仓库可以有多个工作流，每个工作流都可以执行一组不同的任务，例如：
- 构建和测试拉取请求
- 在每次创建发布时，部署应用程序
- 每当创建新提议时，添加标签
可以在另一个工作流中引用工作流。 有关详细信息，请参阅“重新使用工作流”。
有关详细信息，请参阅“写入工作流”。
事件
事件是仓库中触发工作流运行的特定活动。 例如，当有人创建拉取请求、打开议题或将提交推送到存储库时，活动可能源自 GitHub。 此外，还可以通过发布到 REST API 或者手动方式触发工作流按计划运行。
有关可用于触发工作流的事件的完整列表，请参阅触发工作流的事件。
作业
作业是工作流中在同一运行器上执行的一组步骤。 每个步骤要么是一个将要执行的 shell 脚本，要么是一个将要运行的动作。 步骤按顺序执行，并且相互依赖。 由于每个步骤都在同一运行器上执行，因此您可以将数据从一个步骤共享到另一个步骤。 例如，可以有一个生成应用程序的步骤，后跟一个测试已生成应用程序的步骤。
你可以配置作业与其他作业的依赖关系；默认情况下，作业没有依赖关系，并且会并行运行。 当一个作业依赖于另一个作业时，它会等待依赖作业完成，然后才能运行。
例如，对于没有任何作业依赖项的不同体系结构以及依赖于这些版本的打包作业，你可配置多个版本作业。 版本作业并行运行，只要成功完成，打包作业即会运行。
有关详细信息，请参阅“选择工作流执行的操作”。
操作
操作是用于 GitHub Actions 平台的自定义应用程序，它执行复杂但经常重复的任务。 使用操作可帮助减少在工作流文件中编写的重复代码量。 操作可以从 GitHub 拉取 Git 仓库，为你的构建环境设置正确的工具链，或设置对云提供商的身份验证。
您可以编写自己的操作，也可以在 GitHub Marketplace 中找到要在工作流程中使用的操作。
若要在不公开发布操作的情况下在整个企业中共享操作，可以将操作存储在内部存储库中，然后将存储库配置为允许访问同一组织或企业中任何组织拥有的其他存储库中的 GitHub Actions 工作流。 有关详细信息，请参阅“与企业共享操作和工作流”。
有关操作的详细信息，请参阅“共享自动化”。
运行程序
运行器是触发工作流时运行工作流的服务器。 每个运行器一次可以运行一个作业。 GitHub 提供 Ubuntu Linux、Microsoft Windows 和 macOS 运行器来运行工作流****。 每个工作流运行都在新预配的全新虚拟机中执行。
GitHub 还提供 大型运行器（适用于大型配置）。 有关详细信息，请参阅“使用较大运行器”。
如果需要其他操作系统或需要特定的硬件配置，可以托管自己的运行程序。
有关自托管运行程序的详细信息，请参阅“托管您自己的运行器”。
后续步骤
接下来，了解如何规划在企业中推出 GitHub Actions。 请参阅“为企业引入 GitHub Actions”。