Github Action 起步走第一式

 ·  ☕ 6 

Github Action 起步走

由於最近在使用 Github 時不論是 Create 一個新的 Repository 或是 Fork 別人現有的 Project 都會跳出以下提示，為了滿足好奇心就花了一點時間研究了 Github Action 這個新功能。

GitHub Actions 是 GitHub 在美國11/13號全面開放的 CI/CD workflow系統，我們先看看官方的描述。

官方的描述:

GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub.

可以從官方的介紹看出來 GitHub Actions 是一個自動化 CI/CD 的功能，可以直接從GitHub deploy 以及 test 你的 source code。

為什麼要用？

在沒有用 Github Action 之前維運人員可能會透過 WebHook 之類的方式去得知當前 Repository 的狀態，例如 Kubernetes 社群就開發了一個機器人kubernetes/test-infra專門去處理相關的狀態改變並且觸發後續的流程，如 unit test 、intregration test 或是 e2e test(end to end test) ….等等，或是透過其他 CI/CD 工具 如 Jenkins 、 Argo 等等其他工具去建構一個 pipline，Github 開發了Githbu Action 可以幫這我們在 Github Repository 上直接建立自動化部屬以及測試的流程，除此之外 Github 提供了一些吸引開發者去使用的特點。

  • Discovering actions
  • Notifications for workflow runs
  • Disabling or limiting GitHub Actions for your repository or organization
"Managing a workflow run"
"Events that trigger workflows"
"Virtual environments for GitHub-hosted runners"
"Managing billing for GitHub Actions"

常見的用法說明

GitHub Actions有許多常見的用詞，這邊稍微做一些簡單的解說。(這邊我個人認為我解釋得不好，不過還是聽聽吧xD)

  • Continuous integration (CI):

我們可以透過 CI 去 build 以及 test Repository 上的 Source code。可以從 test 得過程快速地檢測錯誤的邏輯（這邊可以包含整個unit test 、intregration test 或是 e2e test(end to end test) ….等等）。

想要了解更多可以上wiki之類的去了解它的定義

  • Continuous deployment (CD)
    CD通常是建築於CI的結果之上，當CI執行成功後會觸發CD，這個步驟基本上是將CI打包好的
    binary檔案部署到各種不同的環境如Test 環境 Staging 等等。客戶的使用者或是測試人員可以快速地得到部署完的環境，並且進行業務邏輯的測試。

  • Workflow file:
    是定義這個 Repository CI/CD 的工作流程(workflow/pipline)的一個 YAML 檔，這個檔案會放在 RepoRepository 跟目錄底下的 .github/workflows 資料夾中。

  • Action:
    Action 組合了多個 Step ，我可以將 Action 打包好並且分享到分享到 GitHub Action 社群。

  • Step:
    是一個執行一個獨立的指令或是執行別人打包好的Action，一個 Job 裡面會包含一到多個Step，Job 裡面的Step 是共用同一個environment與filesystem。

  • Job:
    由一個或是多個Step組成，當有多個Job的時候我們可以定義Job的相依關係與執行流程。Job 可以並行(parallel)執行或是按順序(sequentially)執行。例如Repository 有建立Build Job 以及Test Job ，Test Job 依賴Build Job 的執行結果，如果今天Build Job 執行失敗Test Job 則不會執行。

通常Job執行在不同的Runner(虛擬環境virtual environment).

  • Runner:
    Runner是在執行Job的虛擬環境，我們可以自己建立Runner或是使用Github 代管的Runner ， Runner 會去去監聽 Github Job 的資料，當有 Job 資料產生的時候 Github 會將 Job 下放給某一個 Runner 去執行，一但 Runner 執行完 Job 會將執行結果回報給Github。

Runner 一次只能執行一個 Job 。

  • Artifact:
    Artifacts 就是把某一個 Job 執行完的結果（可能是 binary 檔、 log 檔等等），可以把這一個 Job 執行完的結果送到下一個 Job 。

  • Event:
    當某一個事件產生的時候如 create PR 、create issue 或是 create branch等等，Gitlab 會收到這個消息並且且進行處理。

要怎麼上手使用

Github 有提供一些預設的 Workflow templates給開發者做使用，開發者可以針對不同語言套用不同的樣板。

Github還會分析你Repository 的source code並且推薦你適合的Workflow templates，例如我的Repository 包含Golang的source code ，我們會收到Github 的建議Golang Workflow templates 我們可以以這個模型堆疊我們需要的Workflow。

可以參考actions/starter-workflows查詢Github 官方維護的 Workflow templates。

起手式

先創一個專案再說，我這邊先用 Golang 建立一個非常簡單的WebServer Repo。
如圖所示，我們可以在 Github 上面可以看到這一個提示，問我們要不要建立一個 GitHub Actions 。

這邊點選Set Up Action會跳轉到這個頁面，選擇想要建立的Workflow templates。

這邊可以直接點擊Set up workerflow，點進去後會跳轉到Workerflow 編輯頁面，頁面上可以看見預設的job、steps等資訊。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

name: Go

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:

  build:
    name: Build
    runs-on: ubuntu-latest
    steps:

    - name: Set up Go 1.13
      uses: actions/setup-go@v1
      with:
        go-version: 1.13
      id: go

    - name: Check out code into the Go module directory
      uses: actions/checkout@v2

    - name: Get dependencies
      run: |
        go get -v -t -d ./...
        if [ -f Gopkg.toml ]; then
            curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
            dep ensure
        fi        

    - name: Build
      run: go build -v .

稍微幾解釋一下這個yaml所代表的意義

  • name
    表示這個Workflow的名字
  • on
    表示這個什麼時候會觸發這個Workerflow
    • push
      表示推到這個某一個branch的時候會觸發，這裡預設是master
    • pull_request
      表示像這個某一個branch發出PR的時候會觸發，這裡預設是master
  • job
    裡面會有要執行的步驟與環境設定
    • build
      • name
        表示這個job用來建構程式碼
      • runs-on
        表示這個這個job要執行在什麼虛擬環境上，這裡是ubuntu，可以改成更小的image
    • steps
      表示這個job有多少步驟要執行
      • name
        描述這個這一步要做什麼，這邊預設是Set up Go 1.13
      • uses
        這邊的意思是使用別人寫的action，預設是actions/setup-go@v1
      • with
        可以指定action的參數，這邊指定go用1.13版go-version: 1.13
      • id
        可以在setup上加上一些標記，這邊預設是go
      • run
        如果不要用別人的action想要執行自己的腳本可以用這個參數，如go build -v .

[color=#FF0000]這邊非常粗淺的帶過這些參數所代表的意義，如果想進行更複雜的設定可以參考GitHub Help

這邊設定好自己想要的Workerflow流程後可以按Start commit 提交這一個commit。

Commit 之後可以看到Github Action 被觸發，我們可以點進去看一下CI/CD有沒有過。

這邊就可以看到我在Workflow Build的階段就失敗了xD，可以點進去看為什麼失敗，判斷是不是code寫錯還是哪裡有問題。

點進去後我們發現，原來是go build -v .出錯拉～那我們這邊做簡單的修改再重新提交一次。

將 Build 那一段 run 改成正確的語法，再重新commit。

1
2

      - name: Build
        run:  go build cmd/main.go

再次檢查Github Action 的Workflow是不是都亮綠燈通過拉～

結束語

今天非常簡單的介紹了Github Action的功能，以及怎麼快速的上手使用這個新功能，下次有機會再來介紹他跟docker怎麼整合以及怎麼撰寫自己的action貢獻給Github Action Marketplace 讓大家來使用。

Meng Ze Li
Meng Ze Li
Kubernetes / DevOps / Backend