持续集成CI:基于GitHub的Action回归验证
Posted 天界程序员
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了持续集成CI:基于GitHub的Action回归验证相关的知识,希望对你有一定的参考价值。
第九章 持续集成CI:基于GitHub的Action回归验证
持续集成可以认为是一种优秀的开发实践,它可以在代码变更的时候及时反映代码状态。持续集成需要服务器的支持,可以考虑通过 gitlib ci
或者 jenkins
自己搭建持续集成服务器,更好的办法是使用第三方的持续集成服务,目前比较流行的有:
对于开源项目来讲由于代码无需闭源,完全可以使用第三方持续集成服务。
本章任务
- 创建工作流
Workflow
; - 创建
Job
; - 运行
CI
服务;
Github Action
是一个集成服务,你可以认为它是一台远程运行的服务器。为了让同一台服务器为不同用户提供独立的配置,互不干扰,需要通过容器化技术实现虚拟机。也就是说使用 Github Action
,其实就是在使用虚拟机。更准确地讲,其实就是在配置一个容器,它的配置非常类似于配置 Docker
容器配置。
【task1
】创建工作流 workflow
Github Action
的配置文件需要放在项目根目录下的 .github/workflows
中,每一个配置文件是一个工作流 Workflow
。一个工作流是可以配置多个自动化任务 (Job) 的。
比如,组件库的持续集成分为两个任务 (Job) 。一个任务是运行单元测试进行回归校验,另外一个是自动运行 lint 脚本校验代码风格。 这两个任务之间并没有先后关系,而且可以并行运行。这个时候就可以新建一个工作流并且配置两个任务。
首先创建一个yaml
文件(文件名随意),编写 name
属性,name
属性最终会被显示到 Action 的执行界面中。
然后是确定触发器。所谓的触发器是指什么时候运行这个工作流 (Workflow
),比如设置 push
和 pull_request
时触发,就是在 Github
收到 push
代码时和 pull_request
请求时触发。
我这里文件命名:main.yml
, 路径:.github/workflows/main.yml
name: CI
on:
push:
branches: [ master ] // github默认分支是main,我这里是master
pull_request:
branches: [ master ] // github默认分支是main,我这里是master
jobs:
Lint:
# Lint任务
UnitTest:
# 单元测试任务
【task2
】创建 Job
下面来具体配置每一个Job。 Job 其实是一个运行任务,我们以 UnitTest 单元测试任务举例。
首先需要确定 Job 的 name,这个也会显示在执行界面中。
设定 runs-on
属性
run-on
是为了指定运行环境(Linux or Mac
),其实你可以认为是这个任务虚拟机的环境,Github
可用的虚拟机有:
windows-(xxx version)
ubuntu-(xxx version)
Macos-(xxx version)
设置job的执行步骤
每一个 job 又包含多个 step, 每一个 step 是串行执行的。
你可以假定,在一个空的操作系统上,如果你想进行单元测试,则需要完成如下任务:
- 安装
git
软件; - 检出
checkout
项目代码; - 安装
pnpm
软件; - 使用
pnpm
安装项目代码的依赖库; - 运行
pnpm run test
。
编写 step
可以使用下面三个方式:
run
: 执行 shell 命令行命令;env
: 设置环境变量;uses
: 运行第三方 Action 脚本。
示例:
命令行是一种最好理解的执行方式,比如运行测试:
pnpm run test:run
你可以这样设置:
- name: Run Test
run: pnpm run test:run
但是对于一些比较复杂过程,自己配置起来就比较繁琐了,比如安装git。
首先要考虑不同系统,也需要确定是否有比如 apt-get 或 yum 等包管理工具。还需要运行安装并配置相应的环境变量。好在这些复杂操作大多数还是通用过程,这个时候就会用到 uses 来显神威了。
uses 可以用于Action。Action 可以认为是Github 提前写好的一些常用的脚本,当然这些脚本也支持自己定义。
常见的通用操作包括:
- 部署 (AWS 、App Engine 等各种云);
- 代码 Review ;
- 代码质量检测;
- 监控;
- 通知 (短信、飞书通知、钉钉)。
每个项目都遇到的常用操作,比如 checkout 检出代码、安装 pnpm 依赖等等,这些步骤显然不需要自己编写,直接使用脚本就可以了。
name: CI
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
# Lint:
# Lint任务
UnitTest:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
- uses: actions/checkout@v2
- uses: pnpm/action-setup@v2.1.0
with:
version: 7.2.1
- name: Install modules
run: pnpm install
- name: Run Test
run: pnpm run test:run
其中运行单元测试的命令还进行了一些修改,因为 vitest 是默认伺服模式,也就是说,它不会在运行完成后退出,所以就需要增加一个非伺服模式的命令。
"scripts":
"test:run": "vitest run",
,
【task3
】运行 CI 服务
运行 GitHub Action
比较简单,只需要将工作流配置文件提交并且 push
到 Github
就可以了。
根据触发器的配置,持续集成脚本会在每次提交 push 代码的时候触发。
运行成功的话会显示绿色对钩。
如果失败,那么就会显示 ❌ 并且自动发送邮件通知。
以上是关于持续集成CI:基于GitHub的Action回归验证的主要内容,如果未能解决你的问题,请参考以下文章