BG76 尝鲜Github Action

【原创】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 字段用于定义一系列步骤

(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流程。

閱讀更多 青衣極客 的文章

關鍵字: 尝鲜 Ubunt 使用