CI/CD 平台迁移实践：从 Travis-CI 转移到 Github Action

LCTT 的 CI 已经在 Travis CI 上运转了多年，一致保持着良好的使用体验。自 2019 年 Github 推出了自家的 CI 工具 Github Action 后，咱们就在考虑将 CI 从 Travis-CI 迁移到 Github，以下降维护和沟通的成本，并借助于 GitHub Action Marketplace 实现更强的功能。

最近，由于 TravisCI 屡屡部署出错，而咱们的帐户由于使用的较多，已经超出了无偿使用的限制，以此为契机，将 CI 从 Travis CI 迁移到 GitHub Action。

项目介绍

Translate Project 是 LCTT 翻译组的主要协做项目，几百位译者经过 GitHub 进行围绕开源、Linux、软件工程等领域的文章翻译，从 2013 年来，累计了大量的提交，导致项目下有很是多的文件。

Translate Project 借助于 CI 帮助译者对基本的文章格式和拉取请求进行检查；并定时执行命令，以进行全部的申请检查，对于超时未完成翻译的工做进行回收；对于文章的状态进行标记，生成相应的徽章。

迁移思路

Travis CI 和 Github Action 在使用方面，其实整体差别不会太大，都是基于 YAML 文件格式来编写配置文件。不过，和 Travis CI 不一样的是，Github Action 支持多个不一样的配置文件，所以，你能够根据不一样的场景，设定不一样的配置文件，下降单个配置的文件的复杂度。

此外，因为咱们的脚本中依赖了一些 Travis CI 的环境变量，也须要将其替换为 Github Action 中的相应环境变量，从而确保脚本能够运转。

改造实践

1. 分析以前的 CI 流程

咱们在 TravisCI 上的 CI 配置文件如图

整体能够分为三块：

1. 命令区：说明了安装阶段和执行阶段的操做有哪些
2. 条件区：指定了这个配置文件在哪些条件下会生效
3. 部署区：写明了构建产物如何进行部署

在命令区中，有预置的安装过程和后续的执行过程。在安装过程当中，安装了一些依赖，并将当前的 pages 资源克隆到本地，以继承上一次构建生成的资料。

在条件区则指明了仅做用于 master 分支

在部署区即是将前面命令区的执行结果进行部署。

在实际的执行过程当中，还会根据环境变量不一样，决定是否要执行特定的命令，这部分在后续的改造过程当中，就能够调整部署，拆分到不一样的文件中。

2. 直接套用配置文件

在完成了基本的分析后，就能够创建新的 Action 配置文件了。因为基本的语法很相似，对于其中的很多内容能够进行直接套用。

好比，咱们的配置文件在直接套用后，结果以下

直接套用的文件已经能够直接运行，不过，这里有不少不知足须要的地方，因此须要作一些修改。

3. 恢复 Travis CI 的环境变量

因为咱们使用的 Badge 等生成脚本并不是我所编写，因此在这一次的迁移中，并不打算对齐进行调整，以免出现故障。而脚本中依赖了一些变量，须要将其从新设置出来。

Github Action 提供了一些方法，可让你手动设置环境变量。你能够在你的构建的步骤中，加入以下代码，从而在构建环境中设定 TRAVIS_BRANCH 和 TRAVIS_EVENT_TYPE 环境变量，确保你可使用这个环境变量。

- name: Set ENV variables
        run: |
          echo "::set-env name=TRAVIS_BRANCH::${TRAVIS_BRANCH:-$(echo $GITHUB_REF | awk 'BEGIN { FS = "/" } ; { print $3 }')}" 
          echo "::set-env name=TRAVIS_EVENT_TYPE::$(if [ "schedule" == "${{ github.event_name }}" ]; then echo "cron"; else echo "${{ github.event_name }}"; fi)"

此外，因为 set-env 这个方法相对比较危险，你还须要在环境变量中，开启危险函数的执行。

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      ACTIONS_ALLOW_UNSECURE_COMMANDS: true

4. 拆分配置文件

Github Action 和 TravisCI 不一样的一点是你能够将你的 CI 文件拆分红多个文件，从而下降每个单独的配置文件的复杂度。

根据前面对于流程的分析，能够将咱们的 CI 流程拆分红三个部分：

1. 生成 badge 文件，应当跟随每一次提交进行
2. 生成 status 文件，执行时间较长，能够按期执行
3. 根据拉取请求内容进行整理，作核验

则将咱们的配置文件拆分红三个不一样的文件：

也得益于拆分开，则在 checker 中就能够免于安装一些必要的依赖，从而精简 CI 流程，提高 CI 的执行时间。

5. 测试 CI 的运行状况

在完成了配置文件的编写和拆分后，就能够进行本地的执行测试。Github Action 写完了，不免要执行一下，确保整个流程是正常的。

这个时候你能够安装工具（https://github.com/nektos/act），来在本地执行 Action ，从而确认你的代码执行是正确的。

若是你是 macOS ，只须要执行 brew install act 就能够安装 act 工具，来完成 act 的安装。

安装完成 act ，就能够经过执行 act 命令来在本地执行 Action ，好比，执行 act pull_request 来触发 GitHub 的拉取请求事件

经过本地测试后，再将你的配置文件推送到 GitHub 上，进行生产环境的测试便可。

6. 移除 Travis-CI

经过上述的一些步骤，咱们完成了从 Travis CI 到 GitHub Action 的迁移，此时，就能够移除项目根目录中的 .travis.yml 文件，完全关闭 Travis CI。

7. 替换环境变量

在完成了基本的迁移后，须要对代码中的一些历史问题进行修复。在第三步中，咱们对于 Travis-CI 的环境变量进行替换，但长期维护的项目应当尽可能将这些未标注上下文的信息替换为有文档标注的，所以，咱们须要将其替换。

替换环境变量主要依赖 Github 官方的环境变量说明，你能够参考官方文档。

简化后，配置文件从以前的 27 行，减小至 17 行，变得更加的精简、易懂。

8. 修改 GitHub 的分支保护条件

为了确保修改符合标准，咱们限制了新的拉取请求必须经过 CI 检查，才能合并进入 master 分支，所以，也须要修改相应的分支保护规则，确保设定相应的保护。

一些注意事项

1. 环境变量不一样

若是你依赖了环境变量，则须要进行相应的修改。或者能够像我同样，先经过 set-env 来让本地拥有临时的环境变量，后续再逐步进行迁移。

2. Action 运行依赖要注意安全

Action 执行过程当中会有两个部分。Action 自己流程依赖于 master 分支，但执行过程当中调用的脚本是根据源决定的，所以，从安全角度来看，你应当尽量将全部的流程放在 Action 中，而不是放在你的源码目录中。

3. 如何触发 CI 的 Pull Request 检查？

在进行 Pull Request 测试的时候，须要不断触发不一样的 Commit ，你能够经过执行 git commit --allow-empty -m "Trigger notification" && git push 来触发一个空白的 commit， 推送到 Github 后，就能够再次触发 pull request 的构建，提高构建的效率。

总结

经过对 TravisCI 的流程整理、代码修改等流程，咱们将以前的 Travis-CI 迁移至速度更快、性能更好的 GitHub Action ，一方面能够优化咱们的工做流，另外一方面，也让咱们的代码更加简洁明了。

对于还在使用 Travis CI 的项目来讲，也能够考虑迁移到 GitHub Action 中，来优化本身的工做流。

参考阅读

• https://mauricius.dev/run-and...
• https://jeffrafter.com/workin...
• https://developer.okta.com/bl...