前言
Github之前更新了一个Action功能（应该是很久以前了），可以实现很多自动化操作。用来替代用户自己设置的自动化脚本（比如：钩子+Jenkins）。
由于平时根本不会有需求用到它，毕竟平时都在用公司的CI/CD流程，所以一直没有机会玩Action。
借着春节放假，就自己写个小Demo体验一下。
本文通过实现一个提交代码后自动执行Junit单元测试并输出测试报告的自动化流程小Demo，来快速上手Github Action。
Github Action 是什么？
Github Action官方文档中对自身的定义：
在 GitHub Actions 的仓库中自动化、自定义和执行软件开发工作流程。 您可以发现、创建和共享操作以执行您喜欢的任何作业（包括 CI/CD），并将操作合并到完全自定义的工作流程中。
用人话说，就是你可以给你的代码仓库部署一系列自动化脚本，在你进行了提交/合并分支等操作后，自动执行脚本。
阮一峰Github Action指南中的介绍：
大家知道，持续集成由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作就称为 actions。
很多操作在不同项目里面是类似的，完全可以共享。GitHub 注意到了这一点，想出了一个很妙的点子，允许开发者把每个操作写成独立的脚本文件，存放到代码仓库，使得其他开发者可以引用。
如果你需要某个 action，不必自己写复杂的脚本，直接引用他人写好的 action 即可，整个持续集成过程，就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。
GitHub Actions 有一些自己的术语：
- workflow （工作流程）：持续集成一次运行的过程，就是一个 workflow。
- job （任务）：一个 workflow 由一个或多个 jobs 构成，含义是一次持续集成的运行，可以完成多个任务。
- step（步骤）：每个 job 由多个 step 构成，一步步完成。
- action （动作）：每个 step 可以依次执行一个或多个命令（action）。
看这些介绍和定义，其实比较枯燥，我们直接来看代码实现，在代码中来理解这些定义和指令。
快速上手
给仓库创建新文件夹.github/workflow
首先，用你自己的任意GitHub仓库，在仓库内添加文件夹.github/workflow 或者.github/workflows：
一个库可以有多个 workflow 文件。GitHub 只要发现.github/workflows目录里面有.yml文件，就会自动运行该文件。
撰写你的workflow
一个yml脚本便是Action的核心了，我们新建一个blank.yml，内容如下：
我在代码里做了一些注释，帮助大家理解每个指令的含义。
整个脚本大致的流程如下：
- 指定在push或者pull request时触发脚本执行
- 拉取ubuntu最新版的镜像
- 缓存Maven依赖目录，避免每次都下载全量依赖包，加快执行速度
- 安装Java8
- 指定pom.xml文件路径，随后用Maven编译项目
- 运行Junit单元测试
给项目撰写单元测试代码
ok，写完脚本，我们需要来编写一些测试代码，让Junit有事可做。
我使用了自己的一个仓库，上面有完整的action脚本和测试类代码，供参考：
这是一个Maven仓库，我们在test文件夹内加入测试代码。
上面的测试代码测试的是下面的一个静态方法：
提交代码，触发Github Action执行
将代码commit并push后，点开你的仓库主页，点击Action标签：
可以看到已经有了执行信息。
接着看下我们的Action到底有没有执行，点开Action标签，已经发现了Junit：
可以进行脚本代码的在线编辑：
点进本次commit执行的记录，可以看到，action顺利完成了几个步骤：
点开Maven的构建日志，可以看到我们第一次跑action，所有的依赖还是即时下载的：
单元测试运行的日志输出正常：
为了试验Maven的依赖包是否能够使用到缓存，我们再写几个单元测试，然后commit：
可以看到，新的action日志里直接开始了编译，不再需要下载全量的包：
单元测试页成功执行：
至此，我们的简易入门教程便结束了。
还有很多功能等待探索
当然，这还只是Action的冰山一角，其能做的事情远不止于此：
- 编译打包代码
- 自动上传至公有云/App容器
- 单元测试/代码覆盖率测试/文档同步/发布版本
等着你们的探索。
