怎么玩 Github Actions?
我也不知道什么时候接触的 Github Actions(简称 Actions),记得是因为本地一直构建不出来 Spigot 所以想到了本身服务器就在大陆以外的 Actions,并且通过模仿其他项目和查询 Github 的文档制作了 SpigotBuildAction。
Github Actions 本意应该是配合 Github 本身的服务来达到持续集成和持续交付的目标,但是因为过于强大,所以被很多人用来当免费的算力使用,例如拿来给自己的京东签到等等。我的一个朋友曾经就有一个专门的项目收集这些奇奇怪怪的用法(LF112/gotAction)。但是因为这样子违背了 Github 的原意,所以经过一段时间的管理(封库,封号等),许多这类项目都或多或少的跑路了。提及这一段是为了让你明白那些事情是可以做的,但是那些事情又是不应该做的。
1 | # This workflow uses actions that are not certified by GitHub. |
上面是 Github Actions “Java with Gradle” 的模板,我们拆开来看一下。
精读示例工作流程
首先最开始看到 “#” 的几行,很明显是注释。Github Actions 配置文件使用的是 YAML,所以要用 “#” 来作为注释的开头。
我谁啊?啥时候干什么啊?能干什么啊?
接下来是 name 字段,代表的是在项目的 Actions 页面里看到的名字,通常需要比较简略但是关键的描述这个工作流到底是干什么的。

然后是 on
,代表工作流何时会被执行。这里写了 “push” 和 “pull_request”,分别代表代码从本地 push 到远端(Remote)时,和 Pull Request 被提交时。这里的 “branches” 是筛选器,代表在那个分支被 push 或者 pull_request 时执行,这是可以省略的(如下代码)。你可以参考触发工作流程和触发工作流程事件。
on: [push, fork, pull_request]
permissions
管理这个工作流程的权限。不太需要管他,你可以参考工作流程语法/权限。
粗略的讲一下我要干那些事?
从 jobs 开始,就是非常关键的工作流程具体内容了,通常只会包含一个 Job,例如这里的 build
。里面的 runs-on
规定了运行的操作系统,通常为 ubuntu-latest
或 windows-latest
。
系统都来了,那我到底要干什么?
steps
是真正运行的指令和程序。Github 提供了直接执行控制台指令的 run 和使用其他用户已经帮你封装好的库 use。
踩在巨人的肩膀上!
Github Actions 最奇妙的部分莫过于很多东西只需要引用别人封装好的 Action 就行了,例如 “Set up JDK 11” 就是很好的例子。你只需要通过 with 传入参数,他就帮你吭哧吭哧的把 JDK 给下下来装好了。这里的 use 代表的是一个 Github 项目,你可以直接在前面加上 Github URL 去看看这个项目到底是什么内容,例如 “actions/setup-java@v3” 就是 https://github.com/actions/setup-java。
自己当巨人
虽然这个示例中没有使用到 run,但是为了方便,我还是很常用到直接 run 来跑的步骤,例如 Gradle Build(如下)。但是你一定要注意使用到的脚本文件能不能在你要的系统上执行,例如 gradlew 在 *nix 系统上很有可能就没有执行的权限,要配合 chmod 来用!
1 | steps: |
那么有那些巨人是常用到的呢?
根据我自己的需求,我常会用到这些库。actions 组织是 Github Actions 官方发布的库,可以放心使用。
库名称 | 介绍内容 |
---|---|
actions/checkout | 将项目代码拉取到本地,非常非常常用!难道你项目都没代码的么? |
actions/setup-java | 将 JDK 安装到本地,通常被 JVM 平台的项目使用。 |
actions/upload-artifact | 将构建结果或者日志上传到 Action 页面。![]() |
marvinpinto/action-automatic-releases | 将结果放到新的 Release 中。按需选择,推荐使用 upload-artifact 。 |