LCTT在TravisCI上运行多年，一直保持着良好的体验。自从Github在2019年推出了自己的CI工具GithubAction之后，我们就一直在考虑将CI从Travis-CI迁移到Github，以减少维护和沟通成本，并借助GitHubActionMarketplace实现更强大的功能。项目首页最近因为TravisCI多次部署出错，加上我们的账号因为频繁使用已经超过了免费使用限额，所以我们借此机会将CI从TravisCI迁移到GitHubAction。TravisCI的提醒项目介绍TranslateProject是LCTT翻译团队的主要协作项目。数百位译者通过GitHub翻译了开源、Linux、软件工程等领域的文章。2013年以来积累了大量的投稿，导致项目下的文件很多。TranslateProject使用CI来帮助翻译人员检查基本的文章格式和拉取请求；定时执行命令检查所有应用，超时后回收未完成的翻译工作；标记文章的状态并生成相应的徽章。生成Badge迁移的思路使用了TravisCI和GithubAction，但是整体差别不是太大。它们都是基于YAML文件格式来编写配置文件。不过与TravisCI不同的是，GithubAction支持多个不同的配置文件，因此你可以根据不同的场景设置不同的配置文件，降低了单个配置文件的复杂度。另外，由于我们的脚本依赖了一些TravisCI的环境变量，所以我们也需要在GithubAction中替换成相应的环境变量，以保证脚本能够运行。改造实践1.分析之前的CI流程。我们在TravisCI上的CI配置文件如图所示：配置文件分为三部分：命令区：说明安装阶段和执行阶段的运行情况。Area：这个配置指定文件在什么情况下生效Deploymentarea：描述构建产品如何部署在commandarea，有预设的安装流程和后续的执行流程。安装过程中会安装一些依赖，同时将当前pages资源克隆到本地，继承上次build生成的素材。在条件区指定只作用于master分支。在部署区，部署了之前命令区的执行结果。在基础流程的实际执行过程中，它还会根据不同的环境变量来决定是否执行特定的命令。这部分可以在后续的改造过程中进行调整部署，拆分成不同的文件。构建过程2.直接套用配置文件完成基本分析后，就可以新建Action配置文件了。由于基本语法非常相似，所以很多内容可以直接套用。比如直接应用我们的配置文件后，结果如下。直接应用的文件已经可以直接运行了。但是有很多地方不符合需要，所以需要做一些修改。3、恢复TravisCI的环境变量由于我们使用的Badge等生成脚本不是我写的，所以在这次迁移中，我们不打算调整对齐方式，以免失败。该脚本依赖于一些需要重置的变量。GithubAction提供了一些方法可以让你手动设置环境变量。您可以在构建步骤中添加以下代码，在构建环境中设置TRAVIS_BRANCH和TRAVIS_EVENT_TYPE环境变量，以确保您可以使用该环境变量。-名称：设置ENV变量运行：|echo"::set-envname=TRAVIS_BRANCH::${TRAVIS_BRANCH:-$(echo$GITHUB_REF|awk'BEGIN{FS="/"};{print$3}')}"echo"::set-envname=TRAVIS_EVENT_TYPE::$(if["schedule"=="${{github.event_name}}"];thenecho"cron";elseecho"${{github.event_name}}";fi)"另外，由于set-env方法比较危险，所以还需要在环境变量中开启危险功能的执行。jobs:build:runs-on:ubuntu-latestenv:ACTIONS_ALLOW_UNSECURE_COMMANDS:true4.拆分配置文件GithubAction和TravisCI的区别在于你可以将你的CI文件拆分成多个文件，从而减少单个配置文件的数量复杂度。根据前面的流程分析，我们的CI流程可以分为三个部分：生成badge文件，每次提交后要生成status文件。执行时间长，可以根据pullrequest内容定时执行。为了验证，我们将配置文件拆分为三个不同的文件：由于拆分，我们可以避免在检查器中安装一些必要的依赖项，从而简化CI流程并提高CI的执行时间。5、测试CI的运行配置文件写入拆分后，就可以进行本地执行测试了。GithubAction写好后，必然要执行，以保证整个过程正常。这时候你可以安装工具（https://github.com/nektos/act）在本地执行Action来确认你的代码执行是否正确。如果你是macOS，只需要执行brewinstallact安装act工具即可完成act的安装。act安装完成后，可以在本地执行act命令执行动作，比如执行actpull_request触发GitHub的pullrequest事件，本地测试通过后，将你的配置文件推送到GitHub进行生产环境测试即可。6.移除Travis-CI通过以上步骤，我们已经完成了从TravisCI到GitHubAction的迁移。此时，我们可以移除项目根目录下的.travis.yml文件，彻底关闭TravisCI。7.替换环境变量完成基本迁移后，需要修复代码中的一些历史问题。第三步，我们替换Travis-CI的环境变量，但是长期维护的项目应该尽量把这些没有标注的上下文信息替换成文档化的，所以我们需要替换。环境变量的替换主要看Github官方的环境变量说明，可以参考官方文档。精简后，配置文件由之前的27行缩减为17行，更加精简易懂。名称：LCTT文章Checkeron：pull_request：branches：[master]jobs：build：runs-on：ubuntu-latestenv：PULL_REQUEST_ID：${{github.event.number}}步骤：-使用：actions/checkout@v2with：fetch-depth:0-name:"checkoutmasterbranch&returntopullrequestbranch"运行：CURRENT=$(echo${{github.ref}}|sed"s|refs/|refs/remotes/|")&&gitcheckoutmaster&&gitcheckout$CURRENT-name:runcheckrun:sh./scripts/check.sh;8.修改GitHub的分支保护条件为了保证修改符合标准，我们限制新的pullrequest通过CI检查，合并到master分支。因此，也需要修改相应的分支保护规则，以保证设置相应的保护。一些注意事项1.环境变量不同如果依赖环境变量，需要相应修改。或者像我一样，先用set-env让本地有临时环境变量，然后再逐步迁移。2、动作运行靠安全。Action的执行过程分为两部分。Action本身的流程依赖于master分支，但是执行过程中调用的脚本是根据source来决定的。因此，从安全的角度来说，你应该尽量把所有的进程都放在Action中，而不是你的源代码目录中。3.如何触发CI的拉取请求检查？在做pullrequest测试的时候，需要不断的触发不同的提交。你可以通过执行gitcommit--allow-empty-m"Triggernotification"&&gitpush来触发空白提交。推送到Github后，可以再次触发pullrequest的构建，提高构建效率。总结通过TravisCI流程组织、代码修改等过程，我们将之前的Travis-CI迁移到GitHubAction，速度更快，性能更好。一方面可以优化我们的工作流程，另一方面也可以让我们的代码更加简洁明了。对于仍在使用TravisCI的项目，您还可以考虑迁移到GitHubAction以优化您的工作流程。
