前言：在 CI/CD 和 DevOps 领域中，持续交付和持续部署是一个老生常谈的话题，也属于前端工程化的范畴。持续集成这个术语最早是在 1994 年由 Grady Booch 提出。持续集成是借助工具对软件项目进行持续的自动化的编译打包构建测试发布，来检查软件交付质量的一种行为。而持续部署是基于持续交付的优势自动将经过测试的代码推入生产环境的过程。接下来我们主要来聊聊前端工程化中的持续集成服务（CI）。

目前社区已有一些出色的持续集成服务（CI）的选择：

Jenkins
Travis CI
GitLab CI
CircleCI
GitHub Actions
…

下面我们主要介绍一下 GitHub Actions：

它使用起来比较简单，只要在我们的仓库根目录建立.github/workflows文件夹，然后将我们的工作流配置(YAML 文件)放到这个目录下，就能启用GitHub Actions服务。

GitHub Actions 是什么

Github Actions 是 Github 的持续集成服务（CI），在 2018 年 10 月推出。

我们知道，持续集成（CI）由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作都称为 actions。

很多操作在不同项目里面是类似的，脚本完全可以共享。因此 GitHub 允许开发者把每个操作写成独立的脚本文件，存放到代码仓库并发布到官方市场，使得其他开发者可以直接引用。

GitHub Actions 基本概念

GitHub Actions 有一些自己的术语：

workflow （工作流程）：持续集成一次运行的过程，就是一个 workflow。
job （任务）：一个 workflow 由一个或多个 jobs 构成，含义是一次持续集成的运行，可以完成多个任务。
step（步骤）：每个 job 由多个 step 构成，一步步完成。
action （动作）：每个 step 可以依次执行一个或多个命令（action）。

GitHub Actions 使用

它使用起来比较简单，只要在我们的仓库根目录建立.github/workflows文件夹，然后将我们的工作流配置文件（YAML 格式文件）放到这个目录下。（GitHub Actions 的配置文件叫做 workflow 文件，文件名我们可以任意取，后缀名统一为.yml，比如 ci.yml。一个库可以有多个 workflow 文件，GitHub 只要发现.github/workflows目录里面有.yml文件，就会自动运行该文件）

如下是一个需要 CI 运行 yarn ci 的 workflow 文件示例：

# name 字段是 workflow 的名称。如果省略该字段，默认为当前 workflow 的文件名
name: ci

# on 字段指定触发 workflow 的条件，通常是某些事件，如下是 push 事件和 pull_request 事件触发 workflow
on:
  push:
    # 指定只有 main 分支发生 push 事件时，才会触发 workflow
    branches: [main]
  pull_request:
    branches: [main]

# jobs 字段，表示要执行的一项或多项任务
jobs:
  # 每一项任务的 job_id，这里是 build 作为 job_id
  build:
    # name 字段是任务的说明
    name: build
    # runs-on字段指定运行所需要的虚拟机环境。它是必填字段。有如下三种
    runs-on: ubuntu-latest
    # runs-on: windows-latest
    # runs-on: macOS-latest

    # steps 字段指定每一项任务的运行步骤，可以包含一个或多个步骤
    steps:
      # 步骤名称
      - name: Checkout
        # 使用的 action
        uses: actions/checkout@v3

      - name: Setup Node.js environment
        uses: actions/setup-node@v3
        # 定义的输入参数，每个输入参数都是一个键/值对
        with:
          node-version: 16

      - name: Cache node modules
        uses: actions/cache@v3
        # 该步骤所需的环境变量
        env:
          cache-name: cache-node-modules
        with:
          path: ./node_modules
          key: ${{ runner.os }}-build-cache-node-modules-${{ hashFiles('**/package.json') }}
          restore-keys: |
            cache-node-modules-
      - name: Run ci
        # 该步骤运行的命令或者 action
        run: |
          yarn
          yarn ci

  # 下面运行顺序依次为：job1、job2、job3
  # job1:
  # job2:
  # needs 字段指定当前任务的依赖关系，即运行顺序
  # needs: job1
  # job3:
  # needs: [job1, job2]

更多语法参考：GitHub Actions 的工作流程语法

示例：npm 包自动发布

因为我也会经常的在 Github 上开源一些工具类，同时需要同步发布到 npm 上，因此也是希望代码提交后能自动的实现 npm 包的发布。接下来就主要记录一下使用 GitHub Actions 自动发布 npm 包。

eg：hzzlyxx/eslint-config-ts

1、生成 npm Access Token

creating-and-viewing-access-tokens

登录 npm 官网，在头像下拉选项中选中 Access Tokens 进入界面
点击 Generate New Token 按钮，选择 Automation 或者 publish 选项，再点击 Generate Token 按钮
界面提示 Successfully generated a new token! ，复制生成的 token

2、注入 secret

点击仓库上 Settings 菜单进入设置界面
在左侧菜单栏选中 Secrets/actions 进入，然后点击 New repository secret 按钮，输入表单信息，Name 为 NPM_TOKEN，Value 为上一步生成的 npm Access Token，最后点击 Add Secret 按钮添加完成

3、添加 yml 文件

在仓库根目录建立.github/workflows文件夹，并新建 npm.yml 文件，填写如下内容：

name: publish

on: [push, pull_request]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 16
      - name: Npm Publish
      	uses: JS-DevTools/npm-publish@v1
        with:
          token: ${{ secrets.NPM_TOKEN }}

4、push 代码

保存上面的文件后，将整个仓库推送到 GitHub。

GitHub 发现了 workflow 文件以后，就会自动运行。然后就可以在仓库的 Actions 菜单查看日志，日志默认保存 30 天。

Tips：package 的 version，是由代码库中的 package.json -> version 指定的，如果要重新发布，需要手动修改 version 值。

5、npm 上查看

回到 npm 上，查看账户下的 packages。如果有，说明自动发布成功了。

小结

到这，我们的GitHub Actions持续集成服务（CI）就告一段落了，后续还将探索其他 CI 方案以及前端工程化。

参考

GitHub Actions 入门教程