背景
为了提高研发效率和代码质量，在代码分支合并前，需要使用CI（持续集成）能力对代码进行静态扫描、执行单元测试、代码构建、自动化测试、部署等操作。
技术方案
由于代码目前在Github托管，因此使用Github Action进行CI配置。本文对Github Action进行简要介绍。
概念
GitHub Actions 是一个持续集成和持续交付 (CI/CD) 平台，可以自动化的构建、测试和部署。这里简单介绍重要的概念，详情可参考官方文档
- Workflow（工作流程） 是一个可配置的自动化过程，它将运行一个或多个Job（作业）。 Workflow由签入到存储库的 YAML 文件定义，并在存储库中的事件触发时运行。
- Event （事件）是存储库中触发工作流程运行的特定活动。 比如提交代码时会触发Push事件。
- Job（作业）是工作流程中的一组步骤，它们在同一运行器上执行。 每个步骤要么是将要执行的 shell 脚本，要么是将运行的操作 。 步骤按顺序执行，并且相互依赖。 由于每个步骤都在同一运行器上执行，因此您可以将数据从一个步骤共享到另一个步骤。
- Action（操作）是 GitHub Actions 平台的自定义应用程序，用于执行复杂但经常重复的任务。 使用操作可帮助减少在工作流程文件中编写的重复代码量。
- Runner（运行器）是当Workflow被触发时实际运行应用程序的服务器。每个运行器一次可以运行一个作业。 GitHub 提供 Ubuntu Linux、Microsoft Windows 和 macOS 运行器来运行您的工作流程。
简单总结上述的概念的关系
- 一个Workflow可以定义一组事件进行触发
- 一个Workflow由一个或者多个Job构成
- 一个Job由多个Step构成，每个Step需要定义要执行的Action
- 一个Job需要指定Action集合运行的服务器
Action复用
每个 Action 可以理解为一个独立脚本，因此可以做成代码仓库，使用actions/repoName的语法引用 action。比如，actions/checkout@v3就表示github.com/actions/checkout这个仓库，它代表一个 Action，这里的作用是拉取代码。
为了减少Action编写的重复量，Github官方绝妙的提供了Action官方市场，可以把通用的Action上传上去供大家直接引用。
因此面对特定的需求强烈建议先去官方市场搜索相关的Action，如果有好的Action当然也鼓励大家分享。
Runner评估
Runner是Action实际运行的环境，这里简要介绍下Github原生的Runner，详情可参考官方文档
- 优点，简单快速使用，运维成本低
- 缺点
- 每次都重新初始化环境导致速度太慢
- 机器资源不方便拓展
- 与内网其他应用的交互受限，网络可能被限制
- 应用场景：CI频次不高、集成场景不复杂、建议使用Github原生的Runner。
注意：如果对于Workflow有更高的要求，可能需要购买相关的升级服务，可参考计费详情。
配置示例详解
经过以上的概念准备，现在以实际的Github CI配置进行描述。
Github CI配置是在仓库主目录下的.github/workflows/目录下的yaml文件，这里以创建Golang环境并执行单元测试为示例进行描述
name: learn-github-actions # Workflow名称
on: [push,pull_request] # 触发事件类型，这里是push和PR都会触发Workflow
jobs:
check-bats-version: # Job名称
runs-on: ubuntu-latest # 使用Github的ubuntu Runner，Job操作会在上面运行
steps: # 操作集
- uses: actions/checkout@v3 # 引用https://github.com/actions/checkout 脚本拉取代码
- uses: actions/setup-go@v3 # 引用https://github.com/actions/setup-go 初始化go环境
with:
go-version: 1.14 # 设置引用Action的参数，这里要求Golang的版本是1.14
- run: cd $GITHUB_WORKSPACE && go test # 切换到仓库主目录并执行单元测试，GITHUB_WORKSPACE变量由上述checkout提供
上述的配置文件生效后，在每次提交代码或者创建Pull Request时就会自动执行上述定义的所有Action，既拉取代码、安装Go环境、执行Go单元测试。
操作步骤
| 步骤 | 操作 | 描述 | 备注 |
|---|---|---|---|
| 1 | 创建github ci配置文件 | 在仓库主目录下创建目录.github/workflows/，并在其下创建xxx.yaml | 也可以直接在仓库页面-> Actions->New workflow点击创建 |
| 2 | 修改github ci配置 | 按照上文“配置示例”配置ci执行的各步骤Action | 触发事件参考文档,详细配置语法可参考文档 |
| 3 | 验证 | 提交Commit，验证事件是否触发，以及验证Job是否正常 | 具体执行结果可去仓库页面-> Actions查看 |
为了保证开源代码质量，Github众多开源代码都有CI接入配置，实际案例可参考etcd
总结
更多的拓展功能，快速参考链接如下
- 容器接入，https://docs.github.com/cn/actions/creating-actions/creating-a-docker-container-action
- 自定义Runner，https://docs.github.com/cn/actions/hosting-your-own-runners/about-self-hosted-runners
参考文档
https://github.com/marketplace?type=actions
https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
