【原创】By Blue Geek In 2020-03-30
在软件的产品线中,常常有一个环节——持续集成(CI)。
1. Github提供的资源
github在被微软收购之后,除了推出免费的私有仓库之外,还有提供了一个土豪的功能——Action。Action需要一台能够执行代码的计算机,Github就为每次执行Action功能提供一台虚拟机。
(1) 硬件资源
该虚拟机所具有的硬件资源如下:
<code>A. 2核心的CPU
B. 7GB内存
C. 14GB的SSD/<code>
对于我们这样的小门小户而言,这样的资源完全够用。
(2) 操作系统
有多个操作系统开发经验的朋友基本会有一个共识,即最好开发用的系统与部署使用的系统一致或者至少类型一致。比如,在Windows下开发,然后在Linux系统中部署的话,就会产生很多的麻烦,稍不留神就会造成故障。Github提供了目前最常用的3种操作系统。
YAML工作流程标签是可以在yaml配置文件中使用的符号,这里只需要知道Github Action可以提供Windows、Ubuntu和macOS三种操作系统的虚拟机。如果你的开发环境正在使用的操作系统是其中一种的话,可以选择对应的虚拟机操作系统。
(3) 使用限制
在使用Github Action时面临一些限制,虽然个人或者小团队用户基本不会超越,但我们仍然需要知道这一点。
A. 在workflow中的每个Job都不应超过6个小时,否则会因无法完成而失败。
B. 每个workflow执行实现不能超过72个小时。
C. 自托管Job最多只能排队24个小时。
D. 当前仓库的所有actions执行Github API的频率不能超过1000次/每小时。
E. 并行任务数量的上限见下表
F. 每个workflow的job数量不能超过256个。
2. Github Action的worflow语法简介
github的action功能有仓库根目录下的.github/workflows目录下的.yml后缀文件定义。每一个yaml文件定义一个workflow,一个workflow可以包含若干个job,每一个job可以包含若干个step,这些step会串行执行,每个step包含若干个action。
(1) name
name字段设置当前workflow的名字
(2) on
on 字段用于指明当前workflow启动的时机,我们通常是需要在修改代码库时启动workflow,可以选择push或者pull_request。例如:
<code>on: [push, pull_request]/<code>
我们也可以设置地详细一点,比如master分支发生push事件时启动的配置如下:
<code>on:
push:
branches:
- master/<code>
(3) jobs
jobs 字段用于定义一个任务,如果这些任务存在依赖关系,可以使用need字段加以说明,例如:
<code>jobs:
a_job:
b_job:
need: a_job
c_job:
nedd: [a_job, b_job]/<code>
(4) run-on
run-on 字段用于指定虚拟机的类型
<code>jobs:
build:
runs-on: macos-latest/<code>
就是指在“build”任务中使用“macOS”操作系统的虚拟机。
(5) steps
steps 字段用于定义一系列步骤,每一个步骤以“- name”开始定义该步骤的名字,随后可选择使用“uses”字段引用第三方action或者docker,使用“env”字段设置环境变量,使用“run”字段设置需要运行的指令。其中“uses”和“run”是二选一的必填字段。
(6) action
在“steps”中使用“uses”字段引用的就是action,该action可以自定义,也可以直接引用第三方的。通常我们都是引用github上已经写好的action。比如拉取当前的代码库的master分支的配置如下:
<code>jobs:
build:
runs-on: macos-latest
steps:
- name: Checkout
uses: actions/checkout@master/<code>
关于workflow配置的基本语法就讨论到这里,更加详细的说明和教程,可以参考github官网给出的文档。
3. 一个macOS编译C++程序的例子
这里展示一个在macOS虚拟机中编译C++程序的例子。
(1) C++源码
首先编写一个src/main.cpp文件:
在“src/main.cpp”文件中依赖了gflags、glog以及gtest三个库。
(2) 编写cmake文件
为了便于组织依赖关系,这里使用cmake来编译工程,CMakeLists.txt文件内容如下:
(3) workflow配置
以上的源码和编译依赖都组织完毕,接下来就可以配置workflow了。编写“.github/workflows/main.yml”文件:
这段配置指定了如下的流程:
(1) 当前workflow的名称为TestGithubActions,
(2) 在push事件发生时触发,
(3) 执行build任务,
(4) build任务需要在“macOS”中执行,
(5) 首先在虚拟机系统中安装依赖,
(6) 拉取仓库源码,
(7) 检查源码目录结构,
(8) 编译并执行生成日志文件,
(9) 将日志文件上传到本次workflow的主页。
将以上文件组成的仓库push到github上,即可在“Actions”标签下查看workflow的运行情况。
等到流程走完,就可以看到产出。
通常第一次尝试都没有那么顺利,大多会由于各种问题导致执行失败。可以根据页面中展示的失败步骤日志分析失败原因,然后修正再push。每次执行失败都会自动发送邮件到用户邮箱中。实验成功之后,就可以在自己的项目中使用Github Action功能了,配置好workflow之后就可以让开发人员专注于代码逻辑,而不必分心维护CI流程。