上周摸鱼摸到 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规定什么时候触发 workflowjobs是 workflow 的组成部分，每个 job 是在不同的容器内并行运行的，之间无法直接相互干涉needs可以声明一个工作依赖另一个或多个 job，当这些 job 被完成后才会开始执行runs-on系统环境，目前支持以下几个（以后估计会慢慢加）- Windows Server 2019:
windows-latest - Ubuntu 18.04:
ubuntu-latestorubuntu-18.04 - Ubuntu 16.04:
ubuntu-16.04 - macOS X Catalina 10.15:
macos-latest
- Windows Server 2019:
env定义环境变量，作用域为整个 jobif规定当满足某些条件时才执行这个 jobsteps是 job 的组成部分，step 是顺序执行的env定义环境变量，作用域为当前 step，且你对环境变量的任何更改都不会带到其它 step 或者 job 中if规定当满足某些条件时才执行这个 step，并且可以使用状态检查函数，根据上一个 step 的状态决定是否运行uses声明使用其它 action 作为你的 step，也就是使用其他人写好的 actionwith为 uses 的 action 传入参数，具体看你使用的 action 的说明run运行命令，支持多行，具体看文档shell定义 run 所使用的 shell，具体看文档continue-on-error即使有错误也继续往下运行 steptimeout-minutes规定该 step 的超时时间
timeout-minutes规定该 job 的超时时间strategy定义一些矩阵供 job 使用，详细看文档container容器具体信息，不规定时所有 step 将直接在runs-on规定的环境上运行，详细看文档services声明使用哪些服务，例如nginx或redis等
Tips
- 涉密内容应使用 secrets（如何使用请阅读 Contexts and expression syntax），在项目 settings 中可以设置，此时 workflow 的日志中所有与 secrets 一致的内容都会用
***替换；基于这一特性，若你想隐藏日志中会出现的某些词句，即使它们不需要被当做涉密变量在 workflow 中使用，你也可以将它们设置成 secrets - 可以使用 actions/cache 来缓存一些可以重复利用的文件，例如 node_modules，可以节省时间减少网络开销等
- 当你觉得他人开发的 action 与你的需求相当贴合但就是差了那么一丢丢时，你可以 fork 并自行修改，然后直接用自己改过的 action
坑
- 只有
push,pull_request事件触发的 workflow 可以使用 actions/cache，详见 issue#64 - 在
if内无法访问 secrets 上下文 - 在
if内无法访问同级env- 例如
job.<job_id>.step.if只能访问job.<job_id>.env中定义的环境变量，而不能访问job.<job_id>.step.env中定义的环境变量
- 例如
- 综合 2 和 3，2 的变通解决方式是在上级
env中声明一个环境变量来使用 secrets 的值，并且由于 3 的限制，你只能在 step 上这么操作 - 由于
env的本质是字符串，因此在if中使用env时请注意数据类型- 例如在 job 中声明环境变量
test: ${{ true }}，在 step 的 if 中使用时，条件应当用env.test == 'true'，而不是env.test == true
- 例如在 job 中声明环境变量
- workflow 中产生的事件无法直接触发另一个 workflow 的运行，详见 About workflow events
- 例如 A 是定时运行，会往项目 push 代码，B 会在 push 事件发生时触发，则 A 的运行无法触发 B
版权声明：本文为原创文章，版权归 神代綺凜 所有。
本文链接：https://moe.best/gotagota/github-actions-experience.html
所有原创文章采用 知识共享署名-非商业性使用 4.0 国际许可协议 进行许可。
您可以自由的转载和修改，但请务必注明文章来源并且不可用于商业目的。
4 comments