GitHub Actions Overview#

GitHub Actions 是 2018-08-16 上线的一款由 GitHub 提供的 CI/CD 产品. 微软看中了 GitHub 上无数的开源代码数据, 为了利用这些数据训练 AI, 跟自家的产品深度整合构建护城河, 微软于是于 2018 年 10 月完成了对 GitHub 的收购. 以后 GitHub 背靠微软, 以及 Azure 云, 基本上所有的功能的费用都是同类产品最低, 因为微软根本不打算靠这个挣钱. 虽然 GitHub Actions 跟其他 CI 产品相比资历尚浅, 但是背靠微软这颗大树, 以及没有历史包袱, GitHub Actions 的新功能以及社区活跃度都是同类产品中首屈一指的. 非常值得投入时间学习.

The Nature of CI/CD#

如果你把市场上流行的 CI/CD 产品 (GitHub Actions, GitLab CI, BitBucket Pipeline, CircleCI, Jenkins, AWS CodeBuild) 放在一起看, 跑开各个供应商自己定义的术语和概念, 我们可以发现一个 CI/CD 产品的核心是 Step, Build Job (简称 Job), Workflow (简称 WF) 三部分. 注意, 虽然 GitHub Action 中也有这些概念, 但是本节中提到的是我们总结的抽象概念.

Step 的本质是按顺序执行的一堆 Command Line 命令. 在有些 CI 系统中会有将多个 Step 打包成一个组 (没错, 说的就是 Jenkins 里的 Stage). 但是本质上来说都是对 Step 的封装. 在执行 Step 的时候可能会有一些上下文环境, 例如环境变量, 当前工作目录等. 简单来说, Step 就是对自动化代码级的抽象.
Job 的本质是一个在一个特定的环境 (操作系统, 内存) 中运行许多 Step. 一个 Job 都是一个全新的计算资源, 不同的 Job 中的程序是物理隔离的, 无法互相访问. 每次启动一个 Job 的时候都要重新拉取代码. 而 Job Run 可以被各种各样的事件所触发, 例如 Git push 事件. 大部分 CI 产品都提供了在 Job 之间传递参数, 传递 Artifacts 的功能. 简单来说 Job 是对业务逻辑级的抽象, 也是对一个 CI/CD 工作流的编排.
Workflow 的本质是对 Job 的编排. 不同的 Job 之间的依赖关系可能有顺序执行, 并行执行. Job 出现错误时可能需要立刻停止, 也可以忽略错误继续执行. 有些 CI 系统中 Workflow 也可以对其他 Workflow 进行编排. Workflow 也可以被各种各样的事件所触发, 例如 Git push 事件. 简单来说 Workflow 本身不执行任何代码, 它只是对 Job 的编排.

有了以上三个概念再回头看这些 CI 产品:

GitHub Actions 中, GitHub Action Step 就是上面的 Step, GitHub Action Job 就是上面的 Job, GitHub Action Workflow 就是上面的 Workflow.
AWS CodeBuild 中的 commands 就是 Step, CodeBuild Job Run 就是 Job, CodePipeline 就是 Workflow.

Knowledge Graph#

本节把 GitHub Action 的知识点做了一个总结. 在学习的时候可以照着这个知识图谱来查漏补缺.