前言
说起自动化,无论是公司项目还是个人项目,都会用到或者编写一些工具来帮助我们去处理琐碎重复的工作,以节约时间、提升效率。随着前端工程化越来越明显,做前端开发会涉及诸如构建、部署、单元测试等这些开发工作流中重复的事项,本篇文章将介绍如何利用 GitHub 官方提供的 Actions 来完成前端的自动化发布。
Github Actions
什么是 Actions?
根据 GitHub 官网对 Actions 的定义,GitHub Actions 可理解为在某种条件下可被触发的任务,利用一个个任务(Action)就可组建成我们的工作流。
使用 Actions 的好处
目前,前端自动化部署工具和方案很多,那么 GitHub 推出的 Actions 有什么特别的地方呢?
- 免费
Action 可与 GitHub 中的 Repo 进行绑定,开箱即用。这就意味着我们不需要提供额外的服务器来跑任务,也不用管怎么把任务流对接起来,只要简单地熟悉 Actions 规则,就能将项目跑起来。有时候我们之所以觉得某个工具麻烦,是因为使用步骤繁琐:若要实现功能 A,还需做 B/C/D 操作才行。这时候我们要么放弃,要么转向操作更简单的工具,毕竟省时省事才是我们追求的目标。 - 任务插件化
持续丰富的插件开源市场,得益于 Github 定义了 Actions 规范,让我们使用的 Actions 时都是按某种已知规则开发,这使得 Actions 更易于装配复用。
很多优秀的开发者在制作完成工作流后,将自己开发的 Actions 放到 GitHub 的 Actions Marketplace 上去,这样,尚未完成自己常规工作流的开发,不需要额外开发。重复的任务逻辑,直接使用他人现成的 Actions 即可。在我们使用 Actions 过程中,前端的构建部署工作流,便利用了各类现有的 Actions 组合实现。 - 和 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 }}
的变量访问形式在配置文件中使用。
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 有一定的帮助。