关于ci:CICD-平台迁移实践从-TravisCI-转移到-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…