Github Actions 体验

最近给我的几个 Github 项目都加上了 Actions,实现自动部署到 Github Pages,感觉非常方便。

亮点

社区赋能

Github Actions 出来之后,最让我觉得眼前一亮的优势就是社区赋能

在这个场景下,我的理解是,用户在 Github 社区中可以互相帮助,只需要有一个人开发了 Github Actions 中的一个步骤,就可以让其他人都来用,简化其他人的工作,CI 的配置得到了很大程度的简化。

举个例子,我希望在博客代码更新后,自动部署新版网站。那么可以声明一个这样的 Workflow:

name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - name: Build
      run: yarn && yarn build
    - name: Deploy to GitHub Pages
      uses: JamesIves/github-pages-deploy-action@releases/v3
      with:
        ACCESS_TOKEN: ${{ secrets.GH_PAT }}
        BASE_BRANCH: master
        BRANCH: gh-pages
        FOLDER: dist

跟以前的第三方 CI 模式不一样的地方在于,我们现在可以用配置代替代码,用现成的 Action 服务替代脚本,在社区的帮助下,还可以汇集前人的智慧,加入一些前置校验,也更不容易出错了。

使用上,我们只需要把要干的事情分成几个步骤,每个步骤找一个对应的 Action,写写配置就完成了。如果实在没有也可以自己写一个,方便以后自己和别人复用。这样一来,社区赋能的目的就达到了。

体验提升

除了社区的力量加成,Github Actions 还带来了很多体验上的提升,毕竟是与 Github 深度整合,很多能力第三方 CI 服务都不一定能够触及。

比如:

  • 更多的条件触发,让自动化进行得更彻底;
  • 入口集成在项目中,方便管理;
  • 每一个 Action 都可以是独立的仓库,还可以遵循 semver 发版;
  • 基础的 access_token 权限无需额外配置;(这一条目前存在一些问题,所以有些场景依然需要单独配置😂)

不足

尽管 Github Actions 看上去很美好,但用起来还是遇到了一些问题。

社区混乱

社区的繁荣,带来的一个副作用就是,相似的产品非常多。

比如我希望把静态资源部署到 Github Pages,在 Action 市场一搜索,就得到了 30 个名字很相近、功能也很类似的产品。而且从排序上完全看不出倾向性,最后只好把 star 数目比较多的几个挨个体验了一遍,才选择了上文中出现过的那个。

action github pages

可视化不足

虽然 Github 提供了一个定制化的 Actions 编辑界面,但是给我的感觉是

控制面板不够可视化,现在的交互就是一个 Yaml 编辑器加一个插件列表边栏,不能直观地看出 workflow 的编排,本质上还是在写代码,只不过可以从搜索结果中快速复制一些已有的 Action 的使用配置。

密钥管理复杂

密钥的管理让我很是头疼,比如全局的密钥和项目级的密钥是什么关系,每个密钥的名字又有什么含义,在 Action 中配置密钥的时候,指定的 key 对应的是哪个名字。有限的文档我看了很多遍,似乎也没有看到关于这些细节的说明。

而且密钥出于安全考虑是会被隐藏的,整个 CI 过程不好调试,所以报错为密钥不正确的时候,我感觉很迷,也不知道到底哪里有问题。

影响

第一次看到 Github Actions,感觉省了授权、同步等过程,不用自己去对接第三方了,简单了不少。

然后就想到,第三方 CI 工具要完了,如 TravisCICircleCI,便利性上输了一筹,跟官方的 Github Actions 一比又没什么 killer feature,感觉很难玩了。

看到 Hacker News 上的相关讨论,不少人有一样的担忧,就是官方的强势入场,如果使得最后大一统,市场多样性变少,形成垄断,他们就可以为所欲为了。


© 2020