持续集成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),比如设置 pushpull_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 提前写好的一些常用的脚本,当然这些脚本也支持自己定义。

marketplace

常见的通用操作包括:

  • 部署 (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 比较简单,只需要将工作流配置文件提交并且 pushGithub 就可以了。

根据触发器的配置,持续集成脚本会在每次提交 push 代码的时候触发。



运行成功的话会显示绿色对钩。

如果失败,那么就会显示 ❌ 并且自动发送邮件通知。

以上是关于持续集成CI:基于GitHub的Action回归验证的主要内容,如果未能解决你的问题,请参考以下文章

Travis CI用来持续集成你的项目

利用Travis CI+GitHub实现持续集成和自动部署

Gitlab与Jenkins结合构成持续集成(CI)环境

Jenkins+Github持续集成

基于Jenkins持续集成CI

GitHub 十大 CI 工具