透過 GitHub Action 將 Gatsby 部署到 GitHub Page

August 23, 2020

本文會提到

設定 GitHub Action
透過 GitHub Action 發佈 Gatsby Project 到 GitHub Page
GitHub Action 的計費方式

前言

在 GitHub Action 推出前，
GitHub 最常搭配的 CI 服務應該是 Travis CI，
相信大家有在 GitHub 看開源專案的時候，
看過有些 readme 上的 build pass 小貼紙，
通常都是 Travis CI 的。在近期的 GitHub + Travis CI 實際串接的爬文過程中，
發現 GitHub Action 比剛出的時候似乎改了不少，
想想編譯部落格不太需要繞一圈去搭配一個額外的 CI/CD 服務，
所以決定試試實際串接 GitHub Action。

前置準備

一個 GitHub 帳號
一個在 GitHub 上要佈署的專案

接下來是確認 Pricing，
目前 GitHub Action 很佛心的提供 Open Source Project 的免費使用，
更佛心的點是相比 Travis CI，
GitHub Action Free Plan 直接提供了每個月 2000 分鐘的使用時間，
還提供了 GitHub Action Marketplace，
可以方便套用別人寫好的 GitHub Action。

設定

新增 perrsonal sccess token

首先要新增 perrsonal sccess token，
到 GitHub 的 Settings/Developer/settings/Personal access tokens 下產生一組新的token，
Note 打一組自己會記得的，
如果是 Public Repo 的話選 public_repo，
如果是 Private Repo 的話要選整個 Repo 權限，
記得產生完要記錄起來。

設定 Secrets

到要自動發佈 GitHub Repo的 Settings/Secrets 新增一組 New Secret:

Name:打自己看得懂意思的就好，等等會用到
Value:要填上剛剛產生的token

新增Action

接著到 GitHub 要發佈 Repo 的 Action 頁，
這裡我選擇套用寫好的GitHub Action試試效果。

首先要先建立一個 .yml 檔案，
根據文件要放在以下位置

.
└── .github
    ├── workflows
    └── your-workflow.yml(.yaml 也可以)

參考以下設定

name: Gatsby Publish
# 在 master 有 push 時觸發動作
on:
  push:
    branches:
      - master

jobs:
  # 這個是 job_id
  build: 
    # 指定這個 job 要跑在什麼環境上 要注意 GitHub Runner 每次都會是乾淨環境
    # 可以指定 self-hosted runner 然後宣告成 
    # [self-hosted, windows/linux/macOS,x86/x64/ARM/ARM64]
    runs-on: ubuntu-latest 
    # 每個 job 會有很多的任務，這些任務集合叫做 steps，會依序執行
    steps: 
      # uses 代表套用現成的action
      - uses: actions/checkout@v2 
      - run: npm install
      - run: npm run build
      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          personal_token: ${{ secrets.剛剛設定的SecretName }}
          # 發佈到 GitHub Page 所在 Repo 
          external_repository: {username}/{username}.github.io           
          publish_branch: master
          publish_dir: ./public

都設定正確的話，
當 master 有新的 push 的時候，
就會自動執行設定好的 GitHub Action，
live log 可以在 Repo 下的 Actions 看當次 Workflow 的執行紀錄，
可以很方便看 Workflow 內每個 Actions 的執行時間，
以及當發生錯誤時是哪個環節出錯，
這樣一來就可以完成 push 到 master 後自動部署任務了。

GitHub Action Billing 計算方式

前面有提到，
如果是 Private Repo 的話執行 GitHub Action 要付費，
但是 GitHub 有提供免費額度，
實際使用與剩餘時間是放在帳單頁，
在實際串接 GitHub Action 中我並沒有很順利一次串接成功，
比對了一下實際使用時間，
以及以我串接的紀錄來說:

#4 1m43s
#3 17s
#2 17s
#1 22s

這樣總時數是 2m39s，
而實際帳單是 5 of 2000 min included ，
推測起來 GitHub Action 實際計算方式是一個 Action 最小執行時間單位為一分鐘，
所以算成 4m43，
在帳單頁直接顯示成 5m，
以上是依照結果推測。

Job 平行處理與控制

在這次的實作中其實只使用了一個 job 來完成整個部署，
沒有將 CI 與 CD 拆分，
更沒有程式碼的測試案例，
但其實在實際軟體開發流程中有些情況下會碰到一次部署需要執行多個任務，
比方像是跑單元測試跟原始碼品質檢查等等，
GitHub Action 有支援平行處理 job，
並且可以透過簡單的語法來控制流程，
比方像是:

jobs:
  job1:
  job2:    
  job3:
    needs: [job1, job2]
  job4:
    needs: [job3]

透過 needs 語法就能很好的控制 task 之間的相依性。

ref: