上周摸鱼摸到 GitHub Actions，听说今年 11 月就要正式向大众开放了，试了下蛮好玩的，但局限性和坑点也非常多

Head Pic: #アークナイツ frost - am1m的插画 - pixiv

GitHub Actions

官方介绍说，GitHub Actions 可以自动化和定制化项目的 Workflow，相当于官方钦定的 CI，目前仍处于 beta 阶段，想使用必须去手动点个按钮申请，听说 11 月会正式开放给全员

实际折腾了几天，给我的感受是，得益于 GitHub 这个平台，再加上你的创(xiao)造(nao)力(gua)，Actions 能做到的事情确实很多，但有很多问题十分影响使用体验，后面会一一列出

使用前可以搜索一下已有的介绍文章、阅读官方文档来大致了解，真正使用的话我们主要阅读 Workflow syntax 和 Contexts and expression syntax 文档就行了

你可以在 GitHub Marketplace 浏览寻找其他人开发的 actions，同时我推荐看看 sdras/awesome-actions 这个仓库，它收录了许多 GitHub Actions 相关的内容，并且对官方和他人开发的 actions 的功能做了分类与简略说明，方便你快速找到自己需要的 actions

用例与简单说明

与 Travis CI 相似，GitHub Actions 也使用 YAML 作为配置文件的格式，放在.github/workflows文件夹下

这是一个简单的示例，作用是当我更新 vue 项目文件时自动构建 dist 并发布到 GitHub Pages，然后推送到我的 Coding Pages 所在的远程仓库

下面我简单描述一下 GitHub Actions 中常用的语法，使你可以大概了解它能做什么

• on规定什么时候触发 workflow
  • 可以由push,pull_request,release等事件触发
  • 例如release这种事件可以定义具体类型
  • push,pull_request可以规定涉及具体分支branches、标签tags、路径path时触发
    • 路径可以用包含（path）或忽略（paths-ignore）两种模式，支持通配符，包含模式下可以用!声明例外目录
  • 可以由schedule定时触发，使用 cron 表达式
• jobs是 workflow 的组成部分，每个 job 是在不同的容器内并行运行的，之间无法直接相互干涉
  • needs可以声明一个工作依赖另一个或多个 job，当这些 job 被完成后才会开始执行
  • runs-on系统环境，目前支持以下几个（以后估计会慢慢加）
    1. Windows Server 2019: windows-latest
    2. Ubuntu 18.04: ubuntu-latest or ubuntu-18.04
    3. Ubuntu 16.04: ubuntu-16.04
    4. macOS X Catalina 10.15: macos-latest
  • env定义环境变量，作用域为整个 job
  • if规定当满足某些条件时才执行这个 job
  • steps是 job 的组成部分，step 是顺序执行的
    1. env定义环境变量，作用域为当前 step，且你对环境变量的任何更改都不会带到其它 step 或者 job 中
    2. if规定当满足某些条件时才执行这个 step，并且可以使用状态检查函数，根据上一个 step 的状态决定是否运行
    3. uses声明使用其它 action 作为你的 step，也就是使用其他人写好的 action
    4. with为 uses 的 action 传入参数，具体看你使用的 action 的说明
    5. run运行命令，支持多行，具体看文档
    6. shell定义 run 所使用的 shell，具体看文档
    7. continue-on-error即使有错误也继续往下运行 step
    8. timeout-minutes规定该 step 的超时时间
  • timeout-minutes规定该 job 的超时时间
  • strategy定义一些矩阵供 job 使用，详细看文档
  • container容器具体信息，不规定时所有 step 将直接在runs-on规定的环境上运行，详细看文档
  • services声明使用哪些服务，例如nginx或redis等

Tips

1. 涉密内容应使用 secrets（如何使用请阅读 Contexts and expression syntax），在项目 settings 中可以设置，此时 workflow 的日志中所有与 secrets 一致的内容都会用***替换；基于这一特性，若你想隐藏日志中会出现的某些词句，即使它们不需要被当做涉密变量在 workflow 中使用，你也可以将它们设置成 secrets
2. 可以使用 actions/cache 来缓存一些可以重复利用的文件，例如 node_modules，可以节省时间减少网络开销等
3. 当你觉得他人开发的 action 与你的需求相当贴合但就是差了那么一丢丢时，你可以 fork 并自行修改，然后直接用自己改过的 action

坑

1. 只有push,pull_request事件触发的 workflow 可以使用 actions/cache，详见 issue#64
2. 在if内无法访问 secrets 上下文
3. 在if内无法访问同级env
   • 例如job.<job_id>.step.if只能访问job.<job_id>.env中定义的环境变量，而不能访问job.<job_id>.step.env中定义的环境变量
4. 综合 2 和 3，2 的变通解决方式是在上级env中声明一个环境变量来使用 secrets 的值，并且由于 3 的限制，你只能在 step 上这么操作
5. 由于env的本质是字符串，因此在if中使用env时请注意数据类型
   • 例如在 job 中声明环境变量test: ${{ true }}，在 step 的 if 中使用时，条件应当用env.test == 'true'，而不是env.test == true
6. workflow 中产生的事件无法直接触发另一个 workflow 的运行，详见 About workflow events
   • 例如 A 是定时运行，会往项目 push 代码，B 会在 push 事件发生时触发，则 A 的运行无法触发 B