使用 GitHub Actions 与 Docker 构建 CI/CD 系统_github cicd

技术概述

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: 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43