LV02-GitHubActions-01-了解GitHubActions
GitHub Actions是什么？能干什么？有什么东西？若笔记中有错误或者不合适的地方，欢迎批评指正😃。
点击查看使用工具及版本
| PC端开发环境 | Windows | Windows11 |
| Ubuntu | Ubuntu20.04.2的64位版本 | |
| VMware® Workstation 17 Pro | 17.6.0 build-24238078 | |
| 终端软件 | MobaXterm(Professional Edition v23.0 Build 5042 (license)) | |
| Win32DiskImager | Win32DiskImager v1.0 | |
| Linux开发板环境 | Linux开发板 | 正点原子 i.MX6ULL Linux 阿尔法开发板 |
| uboot | NXP官方提供的uboot，使用的uboot版本为U-Boot 2019.04 | |
| linux内核 | linux-4.19.71(NXP官方提供) |
点击查看本文参考资料
| 分类 | 网址 | 说明 |
| 官方网站 | GitHub Actions 工作流程语法 | GitHub Actions 工作流程语法 - GitHub 文档 - GitHub 文档 |
| YAML官网 | 在这里可以找到YAML的基本语法 |
点击查看相关文件下载
| 分类 | 网址 | 说明 |
| --- | --- | --- |
其实直接看【5】GitHub Actions 指南 - GitHub 文档 - GitHub 文档就可以了，这里只是为了方便自己查看。
一、了解 GitHub Actions
1. 概述
GitHub Actions 是一个持续集成和持续交付 (CI/CD) 平台，允许我们自动化构建、测试和部署管道。我们可以创建工作流来构建和测试我们存储库的每个拉取请求，或者将合并的拉取请求部署到生产环境。
GitHub Actions 不仅限于 DevOps，还允许我们在存储库中发生其他事件时运行工作流。例如，我们可以运行一个工作流，以便每当有人在我们的存储库中创建新问题时自动添加相应的标签。
GitHub 提供 Linux、Windows 和 macOS 虚拟机来运行我们的工作流，或者我们可以在我们自己的数据中心或云基础设施中托管我们自己的自托管运行器。
2. GitHub Actions 的组成部分
我们可以配置 GitHub Actions 工作流，以便在存储库中发生事件时触发，例如打开拉取请求或创建问题。我们的工作流包含一个或多个作业，这些作业可以按顺序或并行运行。每个作业都将在其自己的虚拟机运行器或容器内运行，并且具有一或多个步骤，这些步骤要么运行我们定义的脚本，要么运行操作，这是一种可重用的扩展，可以简化我们的工作流。
2.1 workflows——工作流
工作流是一个可配置的自动化流程，它将运行一个或多个作业。工作流由签入到我们存储库的 YAML 文件定义，并在存储库中由事件触发时运行，或者可以手动触发，或者按照定义的计划触发。
工作流在存储库的.github/workflows目录中定义。一个存储库可以有多个工作流，每个工作流都可以执行不同的任务集，例如
- 构建和测试拉取请求。
- 每次创建发行版时都部署我们的应用程序。
- 每当打开新问题时都添加标签。
我们可以在另一个工作流中引用工作流。有关更多信息，请参阅“重用工作流”。
有关更多信息，请参阅“编写工作流”。
2.2 events——事件
事件是存储库中触发工作流运行的特定活动。例如，当有人创建拉取请求、打开问题或将提交推送到存储库时，活动可能源自 GitHub。我们还可以触发工作流以按 计划运行，通过 向 REST API 发送请求 或手动运行。
有关可用于触发工作流的事件的完整列表，请参阅触发工作流的事件。
2.3 jobs——作业
作业是在同一运行器上执行的工作流中的一组步骤。每个步骤要么是要执行的 shell 脚本，要么是要运行的操作。步骤按顺序执行，并且相互依赖。由于每个步骤都在同一运行器上执行，因此我们可以将数据从一个步骤共享到另一个步骤。例如，我们可以有一个步骤来构建我们的应用程序，然后是一个步骤来测试构建的应用程序。
我们可以使用其他作业配置作业的依赖项；默认情况下，作业没有依赖项并并行运行。当作业依赖于另一个作业时，它会在运行之前等待依赖作业完成。
例如，我们可以为不同的架构配置多个构建作业，而没有任何作业依赖项，以及一个依赖于这些构建的打包作业。构建作业并行运行，一旦它们成功完成，打包作业就会运行。
更多信息，请参阅“选择工作流的功能”。
2.4 actions——操作
操作是 GitHub Actions 平台的自定义应用程序，用于执行复杂但经常重复的任务。使用操作可以帮助减少在工作流文件中编写的重复代码量。操作可以从 GitHub 拉取我们的 Git 存储库，为我们的构建环境设置正确的工具链，或为我们的云提供商设置身份验证。
我们可以编写自己的操作，也可以在 GitHub Marketplace 中查找可在工作流中使用的操作。
有关操作的更多信息，请参阅“共享自动化”。
2.5 runners——运行器
运行器是触发工作流时运行工作流的服务器。每个运行器一次只能运行一个作业。GitHub 提供 Ubuntu Linux、Microsoft Windows 和 macOS 运行器来运行我们的工作流。每次工作流运行都在一个新的、新配置的虚拟机中执行。
GitHub 还提供更大规模的运行器，这些运行器具有更大的配置。更多信息，请参阅使用更大规模的运行器。
如果我们需要不同的操作系统或需要特定的硬件配置，我们可以自己托管运行器。
有关自托管运行器的更多信息，请参阅托管我们自己的运行器。
二、持续集成
1. 关于持续集成
持续集成 (CI) 是一种软件实践，要求频繁地将代码提交到共享存储库。更频繁地提交代码可以更快地检测到错误，并减少开发人员在查找错误根源时需要调试的代码量。频繁的代码更新还可以更轻松地合并来自软件开发团队不同成员的更改。这对开发人员来说非常棒，他们可以花费更多时间编写代码，而花费更少的时间调试错误或解决合并冲突。
当我们将代码提交到存储库时，我们可以持续构建和测试代码，以确保提交不会引入错误。我们的测试可以包括代码 linter（检查样式格式）、安全检查、代码覆盖率、功能测试和其他自定义检查。
构建和测试代码需要服务器。我们可以在将代码推送到存储库之前在本地构建和测试更新，也可以使用 CI 服务器检查存储库中是否有新的代码提交。
2. 关于使用 GitHub Actions 进行持续集成
使用 GitHub Actions 进行 CI 可以提供工作流，这些工作流可以构建存储库中的代码并运行我们的测试。工作流可以在 GitHub 托管的虚拟机上运行，也可以在我们自己托管的机器上运行。有关更多信息，请参阅“使用 GitHub 托管的运行器”和“关于自托管运行器”。
我们可以配置 CI 工作流，使其在发生 GitHub 事件时运行（例如，当新代码推送到我们的存储库时）、按设定的时间表运行，或使用存储库调度 Webhook 在发生外部事件时运行。
GitHub 会运行我们的 CI 测试，并在拉取请求中提供每个测试的结果，以便我们可以查看分支中的更改是否引入了错误。当工作流中的所有 CI 测试都通过时，我们推送的更改就可以由团队成员审查或合并。如果测试失败，则我们的更改之一可能是导致失败的原因。
在存储库中设置 CI 时，GitHub 会分析存储库中的代码，并根据存储库中的语言和框架推荐 CI 工作流。例如，如果我们使用 Node.js，GitHub 将建议一个工作流模板，该模板会安装我们的 Node.js 包并运行我们的测试。我们可以使用 GitHub 建议的 CI 工作流模板、自定义建议的工作流模板，或创建自己的自定义工作流文件来运行 CI 测试。
除了帮助我们为项目设置 CI 工作流外，我们还可以使用 GitHub Actions 在整个软件开发生命周期中创建工作流。例如，我们可以使用 Actions 来部署、打包或发布我们的项目。有关更多信息，请参阅“编写工作流”。
有关常见术语的定义，请参阅“了解 GitHub Actions”。
3. 工作流模板
GitHub 提供了针对各种语言和框架的 CI 工作流模板。
在 actions/starter-workflows 存储库中浏览 GitHub 提供的完整 CI 工作流模板列表。
三、持续部署
我们可以使用 GitHub Actions 直接在我们的 GitHub 存储库中创建自定义持续部署 (CD) 工作流。
1. 关于持续部署
持续部署 (CD) 是一种利用自动化发布和部署软件更新的实践。作为典型 CD 流程的一部分，代码会在部署前自动构建和测试。
持续部署通常与持续集成相结合。有关持续集成的更多信息，请参阅“关于使用 GitHub Actions 进行持续集成”。
2. 关于使用 GitHub Actions 进行持续部署
我们可以设置一个 GitHub Actions 工作流来部署我们的软件产品。为了验证我们的产品按预期工作，我们的工作流可以在部署前构建存储库中的代码并运行我们的测试。
我们可以配置我们的 CD 工作流，使其在发生 GitHub 事件时运行（例如，当新代码推送到存储库的默认分支时）、按设定的时间表运行、手动运行或当使用存储库调度 Webhook 发生外部事件时运行。有关工作流何时可以运行的更多信息，请参阅“触发工作流的事件”。
GitHub Actions 提供了一些功能，让我们可以更好地控制部署。例如，我们可以使用环境来要求在作业继续执行之前获得批准，限制哪些分支可以触发工作流，或限制对密钥的访问。我们可以使用并发性将我们的持续交付管道限制为最多一个正在进行的部署和一个挂起的部署。有关这些功能的更多信息，请参阅“使用 GitHub Actions 部署”和“管理部署环境”。
3. 使用 OpenID Connect 访问云资源
如果我们的 GitHub Actions 工作流需要访问支持 OpenID Connect (OIDC) 的云提供商的资源，我们可以配置我们的工作流以直接向云提供商进行身份验证。这将使我们能够停止将这些凭据存储为长期密钥，并提供其他安全优势。有关更多信息，请参阅“关于使用 OpenID Connect 加强安全性”
4. 工作流模板和第三方操作
GitHub 为多种流行服务（例如 Azure Web App）提供了部署工作流模板。要了解如何开始使用工作流模板，请参阅“使用工作流模板”或浏览完整的部署工作流模板列表。我们还可以查看GitHub 针对特定部署工作流的更详细指南，例如“将 Node.js 部署到 Azure 应用服务”。
许多服务提供商还在 GitHub Marketplace 上提供用于部署到其服务的 action。有关完整列表，请参阅GitHub Marketplace。
四、换句话说？
哎，上面看完其实还是不是很懂，看了一下阮一峰哪个教程，感觉好理解一点。
持续集成由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作就称为 actions。
很多操作在不同项目里面是类似的，完全可以共享。GitHub 注意到了这一点，想出了一个很妙的点子，允许开发者把每个操作写成独立的脚本文件，存放到代码仓库，使得其他开发者可以引用。
如果我们需要某个 action，不必自己写复杂的脚本，直接引用他人写好的 action 即可，整个持续集成过程，就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。
GitHub 做了一个官方市场，可以搜索到他人提交的 actions。
另外，还有一个 awesome actions 的仓库，也可以找到不少 action。上面说了，每个 action 就是一个独立脚本，因此可以做成代码仓库，使用userName/repoName的语法引用 action。比如，actions/setup-node就表示github.com/actions/setup-node这个仓库，它代表一个 action，作用是安装 Node.js。事实上，GitHub 官方的 actions 都放在 github.com/actions 里面。
既然 actions 是代码仓库，当然就有版本的概念，用户可以引用某个具体版本的 action。下面都是合法的 action 引用，用的就是 Git 的指针概念，详见官方文档。
1 | actions/setup-node@74bc508 # 指向一个 commit |
参考资料：
【1】GitHub Actions 入门教程 - 阮一峰的网络日志
【2】GitHub Actions 工作流程语法 - GitHub 文档 - GitHub 文档