技术概述
CI/CD 即持续集成/持续部署,是一种软件开发实践,通过自动化的软件流程来构建、测试、部署软件。通过使用 CI/CD,开发团队可以更快地构建和交付出高质量的软件。
技术详述
CI 部分
工具选择
项目开始之初,我计划使用 Gitea 自建 Git,作为我们项目的代码仓,使用 Drone 作为 CI 工具。考虑到大部分组员还不会熟练使用 Git,我便改用了 GitHub 作为代码仓,因为其提供了 GitHub Desktop 这一桌面客户端,比较照顾敲不来命令的同学(项目刚开始不就大家就能较为熟练地使用 Git,非常欣慰)。
正好 GitHub 向公开仓库提供了免费的 Actions 工具,我便决定使用 GitHub Actions 作为 CI 工具。GitHub Actions 与 Drone 相比,有以下几个优点:
- 无需自建服务器,无需自己维护 CI 服务器
- Actions Markets 提供了大量 CI 工具模板,无需每一个流程都手动创建(例如编译 Docker Image 由自己创建将非常麻烦)
- 与 GitHub 其他服务(特别是 Pull Request)结合紧密,可以将测试执行结果直接反馈到 Pull Request 中
技术实现
想要使用 GitHub Actions 作为 CI 工具很简单,只需先考虑清楚要对代码进行哪些测试,然后编写对应的脚本就可以了。
下面展示 YACW 项目前端 CI 测试的配置,将在配置的注释中解释如何构建这个脚本:
# 测试名称
name: ESLint
# 测试的触发器,即什么时间点执行测试
on:
# 时间点1:在 main 和 dev 分支接收 push 时
push:
branches: [ "main", "dev" ]
# 时间点2:在 main 和 dev 分支接收 pull request 时
pull_request:
branches: [ "main", "dev" ]
# 测试的任务
jobs:
# 任务1:eslint
eslint:
# 任务名称
name: Run eslint scanning
# 任务运行环境,一般设置为 ubuntu-latest,即最新 TLS 版本的 Ubuntu
runs-on: ubuntu-latest
# 配置 Actions 执行权限,这里设置为只读取代码,写入安全事件,读取 Actions 运行状态
permissions:
contents: read
security-events: write
actions: read
# 该任务的步骤
steps:
# 步骤1:检出代码
- name: Checkout code
uses: actions/checkout@v3
# 步骤2:安装前端程序所需要的依赖,还额外安装了向 GitHub 上传扫描结果的依赖(eslint-formatter-sarif)
- name: Install Dependencies
run: |
npm install
npm install @microsoft/eslint-formatter-sarif@2.1.7
# 步骤3:运行 eslint 扫描,将扫描结果输出到 eslint-results.sarif 文件中
- name: Run ESLint
run: npx eslint src/
--config .eslintrc.js
--format @microsoft/eslint-formatter-sarif
--output-file eslint-results.sarif
continue-on-error: true
# 步骤4:上传扫描结果到 GitHub
- name: Upload analysis results to GitHub
uses: github/codeql-action/upload-sarif@v2
with:
sarif_file: eslint-results.sarif
wait-for-processing: