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 使用