使用 Github Actions 实现前端自动化发布

前言

说起自动化,无论是公司项目还是个人项目,都会用到或者编写一些工具来帮助我们去处理琐碎重复的工作,以节约时间、提升效率。随着前端工程化越来越明显,做前端开发会涉及诸如构建、部署、单元测试等这些开发工作流中重复的事项,本篇文章将介绍如何利用 GitHub 官方提供的 Actions 来完成前端的自动化发布。

Github Actions

什么是 Actions?

根据 GitHub 官网对 Actions 的定义,GitHub Actions 可理解为在某种条件下可被触发的任务,利用一个个任务(Action)就可组建成我们的工作流。

GitHub Actions 入口
GitHub Actions 入口

使用 Actions 的好处

目前,前端自动化部署工具和方案很多,那么 GitHub 推出的 Actions 有什么特别的地方呢?

  1. 免费
    Action 可与 GitHub 中的 Repo 进行绑定,开箱即用。这就意味着我们不需要提供额外的服务器来跑任务,也不用管怎么把任务流对接起来,只要简单地熟悉 Actions 规则,就能将项目跑起来。有时候我们之所以觉得某个工具麻烦,是因为使用步骤繁琐:若要实现功能 A,还需做 B/C/D 操作才行。这时候我们要么放弃,要么转向操作更简单的工具,毕竟省时省事才是我们追求的目标。
  2. 任务插件化
    持续丰富的插件开源市场,得益于 Github 定义了 Actions 规范,让我们使用的 Actions 时都是按某种已知规则开发,这使得 Actions 更易于装配复用。
    很多优秀的开发者在制作完成工作流后,将自己开发的 Actions 放到 GitHub 的 Actions Marketplace 上去,这样,尚未完成自己常规工作流的开发,不需要额外开发。重复的任务逻辑,直接使用他人现成的 Actions 即可。在我们使用 Actions 过程中,前端的构建部署工作流,便利用了各类现有的 Actions 组合实现。
  3. 和 GitHub 完美集成
    可避免因为使用 Travis 等第三方工具引起额外的心智负担,在 GitHub 上可直接查看 CI/CD 的情况。

除了上面提到的 3 点以外,Actions 还有许多其他好处,可以亲自尝试一下,毕竟自己动手一遍比别人说千遍更容易上手。

GitHub Actions 实践

Actions 快速开始

使用 GitHub Actions 是很容易的事,只需要把你的 Repo 源同 GitHub 关联,关联之后根据以下操作就能实现你的前端部署自动化。

在 Repo 的根目录中,创建一个名为 .github/workflows/ 的文件夹,用来存放工作流的描述文件,一个项目可以有多个工作流,这里我们的工作流为前端的发布。

然后,在创建好的 .github/workflows/ 目录中,以 .yml 为扩展名创建对应该工作流的描述文件,命名可自定义,例如:publish.yml

接下来,参考 GitHub 提供的工作流描述规则进行任务 Actions 配置(详细可以看官方文档),当然,要是觉得文档冗长,可在网上随便搜个简单的例子来试试,亲自测试一下很快就能摸清 Actions 配置套路。

下面是网站自动发布工作流的配置摘要,加了少量注释以帮助大家理解:

name:
on:
  push:
    branches:
      - master

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # 此处每一个 name 对应着一个 Action,具体执行逻辑已被提供者进行封装,暴露给用户的只是需要用户需要关心和配置的
    # 从 master 上获取最新代码
    - name: Checkout Github Action
      uses: actions/checkout@master

    # 网站使用 Hugo 框架进行构建,此处是下载相关环境
    - name: Setup Hugo
      uses: peaceiris/actions-hugo@v2
      with:
        hugo-version: '0.65.3'

    # 为了将资源部署到云服务器,此处下载一个 ssh 传资料的工具
    - name: Setup sshpass
      run: sudo apt-get install sshpass

    # 进行前端资源的构建
    - name: Build
      run: hugo --minify -d example-website

    # 部署
    - name: Deploy
      uses: garygrossgarten/github-action-scp@release
      with:
          local: example-website
          remote: /home/wwwroot/example-website
          # 涉及偏安全隐私的信息,不要明文暴露在此文件中,因为 repo 很可能是公开的,会被所有人看见
          # ${{ ... }} 会应用你在对应项目设置中,配置的对应 serets 的键值信息,从而保护私密信息不被看到
          host: ${{ secrets.HOST }}
          username: deployer
          password: ${{ secrets.PASSWORD }}
          concurrency: 20

最后,提交相应改动,将分支推到远端。只要符合工作流中我们预先定义好的触发规则,对应的操作即可被触发。

完成以上步骤,就能使你的工作流 run 起来,更详细的介绍,可以看下 GitHub 提供的帮助文档,此处就不再赘述。

Actions 使用注意事项

1、私密信息保护

.yml 工作流配置文件中,不要出现私密信息,诸如:账号、密码ip 等等,具体实操过程中你可将这类信息通通放到 Repo 的 secrets 设置中添加,并以 ${{ secrets.xxx }} 的变量访问形式在配置文件中使用。

在 Repo 中添加 Secrets
在 Repo 中添加 Secrets

2、寻找合适 Action

在配置我们的工作流中,我们的目的是为了快速高效地完成工作,因此,大可不必每次都亲自开发需要用到的 Action。通常,我们可以考虑在 Actions 市场找寻已有的 Actions 直接使用。

对于一些处理敏感任务的 Actions,比如,上传服务器时若需将账号、密码传给此 Actions,使用前最好查看下这个 Actions 的具体实现。一方面,能预知其中是否存在风险;另一方,也能满足好奇心,了解相应的 Actions 规范和实现机制,为自己开发 Actions 做技术积累。

3、发挥你的想象力

根据实际的需要,我们的工作流搭配可能会有各类形形色色的需要,比如,笔者最开始使用 GitHub Actions 时,需要连接 VPN 才能访问开发服务器,刚开始没太理解如何连接怕麻烦弄不了,后面慢慢找到对应的 VPN 命令工具做实验并理解这个调用过程后,很快地实现了想要的效果。

这里想说的就是,只要需求合理,肯定不只你一个人会遇到,而此时就会有两种对应的解决办法,一是运气好,有现成的 Actions 等你使用;二是麻烦点,自己用脚本来描述,总之要有想象力。

4、考虑免费 runner 的性能

runner 就是执行配置工作流的环境,是由 GitHub 免费提供给用户使用。当然,既然是免费,大概率意味着性能容量有限,对于一些大型项目的工作流来说,有时候免费的 runner 跑起来有些慢不满足需求,此时可考虑自己提供 runner 来集成,感兴趣的可查看 Self-hosted runners 官方指引。

Actions 实践小结

上面描述了前端日常开发中使用 GitHub Actions 的过程和总结,Actions 还能完成更多不同类型的任务流程,比如持续集成,应该只有想不到没有做不到的道理。

通过项目下的一个个工作流,能从各个方面避免重复琐碎的工作,让我们更专注于实现逻辑本身,这是工程师最希望达到的状态。

感谢阅读,希望这篇文章对你理解 GitHub Actions 有一定的帮助。

分享