Github Action是自动化构建和自动化部署中一个非常好用的工具，准确来说，它是GitHub推出的一个“持续集成”的工具，可以通过构建一系列的工作流来完成项目的打包、发布或部署等。因为最近有一个项目需要用到Github Action，我快速上手后打算系统学习一下，顺便补一补一些软工的概念，特做此笔记。

什么是CI/CD

CI：持续集成

在使用Github Action之前，我先简单介绍一下持续集成的概念。

持续集成（Continuous Integration, CI）是一种软件开发实践，指的是开发人员经常将代码集成到共享的代码库中，每次集成都会通过自动化构建、测试等流程来验证代码是否有效。其主要目的是快速发现问题，确保代码库的稳定性，减少开发到部署之间的时间和复杂性。

CI主要由以下几个部分组成：

1. 代码版本控制：通常使用Git等工具，开发者频繁提交代码到版本控制系统（如GitHub或GitLab）。

2. 自动化构建：每次代码提交后，CI系统会自动构建项目，比如在Java中编译源码，或者在JavaScript项目中打包静态文件。

3. 自动化测试：CI系统会运行预先编写的单元测试、集成测试，确保提交的代码没有破坏已有功能。

4. 静态代码分析：可以集成代码质量工具，如ESLint、SonarQube，自动检测代码规范和潜在问题。

5. 部署准备：构建和测试成功后，CI可以将构建后的产物（如压缩包、Docker镜像等）准备好，便于后续的部署流程（通常和持续交付结合）。

CD：持续交付

持续交付（CD, Continuous Delivery）是在持续集成的基础上，进一步确保每次代码更改都可以通过自动化测试和构建，随时准备好部署到生产环境。虽然每次更改并不一定立刻部署到生产，但可以保证代码在任何时候都能稳定地部署。

GitHub Action与CI/CD的关系

GitHub Actions 是 GitHub 提供的一个自动化工具，可以用来实现 CI/CD 流程。你可以使用 GitHub Actions 创建工作流（Workflows）来自动执行构建、测试和部署任务。

GitHub Actions 能与 CI/CD 结合的方式包括：

• 持续集成：每次有代码提交时，GitHub Actions 可以自动运行构建任务和测试，确保代码能够顺利集成。

• 持续交付/部署：在代码通过测试后，GitHub Actions 可以自动将构建好的应用发布到服务器、云平台或者生产环境，实现交付或部署。

Github Action的快速入门

Github Action的基本概念

workflow：工作流。表示一次持续集成的运行过程。
job：任务。一个workflow可以包含多个job，即一次持续集成的过程可以完成多个任务。
step：步骤。每个job是由多个step构成了，构成一个执行链。
action：每个step中做什么，例如可以执行一系列命令。

yml文件的编写

GitHub Actions通过配置文件的方式来编排工作流，使用的是yml格式，其配置文件要存放在代码仓库的.github/workflows目录。

一个工作流代表对应一个yml文件，一个库可以有多个 workflow 文件。GitHub 只要发现.github/workflows目录里面有.yml文件，就会自动运行该文件。

下面介绍配置文件中的基本字段：

name：workflow的名字，建议配置好各种name，让其他团队成员能快速了解整个构建过程。
on：触发workflow的条件，通常是某些事件，例如push、pull_request等，还支持事件触发或者定时器触发。
on.push.branches/tags：触发时可以限定标签或分支。
jobs：表示要执行的一项或多项任务。每个任务都有唯一的job_id，job.your_job_id.name是对任务的说明，也建议表述清楚。
jobs.your_job_id.needs：指定任务的依赖关系，关系到执行顺序。

例子：


jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

上面代码中，job1必须先于job2完成，而job3等待job1和job2的完成才能运行。因此，这个 workflow 的运行顺序依次为：job1、job2、job3。

jobs.job_id.runs-on：指定临时虚拟容器的环境，支持ubuntu和windows，甚至是macos。
jobs.job_id.steps：指定job的多个运行步骤。
1. name：步骤名
2. run：执行的命令，比如各种bash命令。
3. with：设置环境变量。

实践：Vue项目的自动报告

如果上面的东西都很懵，可以直接看实践部分的配置文件，再回过头去理解其中的一些概念。下面以“实现Vue项目的自动打包”这样一个需求为例，探索一下怎么使用Github Action。

下面是一个完整的配置文件，作用是将vue项目打包并放到artifacts上面，其他团队的成员就可以到上面去下载打包后的文件。

当然，一般来说可以继续配置自动化部署到服务器上面，或者自动化构建为docker镜像，然后再自动化部署，网上已经有了很多解决方案，感兴趣的读者不妨自己动手试一试。

配置文件如下，加了详细注释：

name: poem-build
on:
  push:
    branches:
      - main # 有提交push到main分支时触发
jobs:
  poem-build: # 任务id，可以自己取名
    runs-on: ubuntu-latest # 基于ubuntu镜像
    steps:
		# 第一步，拉代码，用别人写好的action
      - name: Checkout代码
        uses: actions/checkout@v4
		# 第二步，使用Node环境，用别人写好的action
      - name: 使用Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18.x'
		# 第三步，可以打印一下当前路径，看看要不要cd到目录，打印后我发现已经cd了
      - name: 路径打印测试
        run: |
          pwd
          ls -la
		# 第四步，安装node依赖
      - name: 安装依赖
        run: |
          npm install
		# 第五步，打包
      - name: 构建项目
        run: |
          npm run build
          tar -czvf poem.tar.gz dist/
		# 第六步，上传到artifacts
      - name: 尝试将代码发布为构件
        uses: actions/upload-artifact@v3
        with:
          name: poem-dist
          path: ./poem.tar.gz

随着做过的项目越来越多，后续可以多收集一些常见的github action配置文件，这样就可以很容易地将项目进行部署。

CI/CD初探：GitHub Action的使用