前言

说起自动化，无论是在公司还是我们个人的项目中，都会用到或者编写一些工具来帮助我们取处理琐碎重复的工作，以节约时间提升效率，尤其是我们做前端开发会涉及诸如构建、部署、单测等开发工作流中一些重复的事情，本篇文章就是介绍如何利用Github提供的Action来完成我们前端的发布自动化。

Github Action

  • 什么是Action

    就个人简单理解看，就是在某种条件下可被触发的任务，利用一个个任务（Action）就可组建成我们的工作流，想要更详细的介绍定义的同学可以移步 官方Action定义，有助获取更多的信息，这里就不搬运啦~

  • 使用Action方便在哪里

    • 免费，与github中的repo绑定，开箱即用：这就意味着我们不需要提供跑任务的机器，也不用管这么把任务流对接起来，只要简单熟悉规则，就能run起来。要知道很多时候嫌麻烦，想要实现A，要做B/C/D的时候，我们就果断放弃了，万事开头难~

      1.  ![github action.png](https://cdn.nlark.com/yuque/0/2020/png/88240/1582995284816-dc1f45c4-09f1-417e-85bd-250f71fc641a.png#align=left&display=inline&height=152&name=github%20action.png&originHeight=227&originWidth=1007&size=106868&status=done&style=none&width=676)

    • 任务插件化，持续丰富的插件开源市场：得益于Github定义的Action规范，使得我们使用的Action都是按某种规则开发出来的，使得Actions易于装配复用，很多优秀的开发者在完成自己工作流后，将自己发开的Action放到Github的 Actions集市 上去，让更多的人在完成自己常规的工作流时，不需要额外再开发这些重复的逻辑，比如我们实现前端的构建部署工作流，就是用的各类现成的Action组合起来的。

    • 更多好处还待亲自尝试，反正用的都说好😬

我们的实践

需求来源

因为我们是一家开源图数据库（Nebula），项目均是依托于Github来管理的，所以自然使用了免费提供的Action来完成我们日常的持续集成等工作流，前端也不例外。举个例子，我们开发了一个专门介绍Nebula图数据库的官网，除了开发人员根据需求修改站点主题模板之外，日常主要由运营同学来管理内置的博客内容的维护，这个动作比较高频，基本上每两三天运营同学就会发布一篇技术性相关的博客文章，为了让这个动作不依赖于开发同学参与也能实现站点的实时部署更新，就需要将此过程自动化，这便是我们前端日常使用Github Action的主要场景之一。

如何上手

要使用Action很容易，前提是你的repo源是与Github关联的，那么只需要根据以下步骤就能实现你的自动化：

  1. 首先，在repo的根目录中，创建一个名为 .github/workflows/ 的文件夹用来存放里的工作流，一个项目可以有多个工作流，这里我们的工作流就是前端的发布，。
  2. 然后，就是在创建好的 .github/workflows/ 目录中，以 .yml 为扩展名创建对应该工作流的描述文件，命名自定义，例如：publish.yml
  3. 接着，就是参考Github提供的工作流描述规则进行你的任务Action的配置，详细可以看官方文档，当然觉得文档冗长的可以在网上随便搜个简单的例子直接复制试试，亲测很快就能摸清套路。下面是我们自己实现官网自动发布工作流的配置摘要，加了少量注释帮助大家理解： ```yaml name: on: push: branches:
    • master

jobs: build-and-deploy: runs-on: ubuntu-latest steps:

  1. # 从master上获取最新代码
  2. - name: Checkout Github Action
  3.   uses: actions/checkout@master
  5. # 我们的站点使用Hugo框架进行构建，此处是下载相关环境
  6. - name: Setup Hugo
  7.   uses: peaceiris/actions-hugo@v2
  8.   with:
  9.     hugo-version: '0.65.3'
  11. # 为了将资源部署到云服务器，此处下载一个ssh传资料的工具
  12. - name: Setup sshpass
  13.   run: sudo apt-get install sshpass
  15. # 进行前端资源的构建
  16. - name: Build
  17.   run: hugo --minify -d nebula-website
  19. # 部署
  20. - name: Deploy
  21.   uses: garygrossgarten/github-action-scp@release
  22.   with:
  23.       local: nebula-website
  24.       remote: /home/vesoft/nebula-website
  25.       # 涉及偏安全隐私的信息，不要明文暴露在此文件中，因为repo很可能是公开的，会被所有人看见
  26.       # ${{ ... }} 会应用你在对应项目设置中，配置的对应serets的键值信息，从而保护私密信息不被看到
  27.       host: ${{ secrets.HOST }}
  28.       username: vesoft
  29.       password: ${{ secrets.PASSWORD }}
  30.       concurrency: 20

```

  1. 最后，便是提交相应改动，将分支推导远端，只要符合工作流中的对于触发规则的描述就能触发，比如我们的官网仅限master代码变动。

完成以上步骤，就能使你的工作流 run 起来，更详细的介绍，github提供的帮助文档都有，此处就不再多说了。

注意事项

  • 私密信息保护

    .yml 工作流配置文件中，不要出现私密的信息，诸如账号、密码、ip等等，将这类信息通通放到repo的secrets设置中去添加，以 ${{ secrets.xxx }} 的变量访问形式在配置文件中使用。

  • 寻找合适的Action

    在配置我们的工作流中，基于我们的目的是为了快速高效的完成我们的工作，因此不可能去亲自开发每一个需要用到的Action，都会去现成的 Action市场 找来直接使用。其中对于一些处理明感任务的Action，比如上传服务器类似操作，会将账号密码传给此Action时，使用前最好可以去看看这个Action的实现，一来能预知其中是否存在的风险，二来也能满足好奇心了解相应的Action规范和实现机制，能帮助到下次自己开发Action做铺垫。

  • 发挥想象力

    根据实际的需要，我们的工作流搭配可能会有各类形形色色的需要，比如我们最开始使用Github Action的时，需要连接VPN才能访问开发服务器，刚开始没太理解觉得有些麻烦怕弄不了，后面慢慢找到对应的VPN命令工具做实验并理解这个过程后，很快就实现了想要的效果。这里想说的就是，只要需求合理，肯定不止你一个人会遇到，就会有对应的解决办法，有时候可能是现成的Action，有时候稍微麻烦点需要自己用脚本来描述，总之要有想象力~

  • 考虑免费runner的性能

    runner就是执行配置工作流的环境，是github免费提供给用户使用的，当然免费也意味着性能容量有限，对于一些大型项目的工作流来说，有时候免费的runner跑起来有些慢不满足需求，可以考虑自己提供runner来集成，比如像我们的 Nebula 这样大的项目就自己提供了runner环境，详细可看 Self-hosted runners 官方指引。

小结

  1.   以上便是我们在日常前端开发中使用Github Actions的心得体会，Action还能完成更多不同类型的任务流程，比如持续集成，应该只有想不到没有做不到的道理。通过项目下的一个个工作流，能从各个方面避免重复琐碎的工作，让我们更专注于实现逻辑本身，我想这是工程师最希望达到的状态。希望这里的简短介绍能给各位带来帮助，另外欢迎大家关注和使用我们的 [Nebula开源图数据库](https://github.com/vesoft-inc/nebula)，谢谢🤝