在上個章節我們介紹了關於 GitHub Actions 的基礎用法，在這個章節我們將分享什麼是 Self-hosted runners，會有這個議題主要是因為，在後面第三個部分「Robot Framework 結合 Appium 進行 App (Android, iOS) 自動化測試」時，當今天我們的測試需要運行在實體機時，會發現 GitHub Actions 提供的機器是一台遠端的機器，如果我們需要跑我們手上的裝置他是無法連線的，因此這時候我們可以選擇雲服務平台提供的雲裝置，或是自己架設我們的裝置，後者的費用會相對於雲服務平台來中較低，因此實際使用情況大家還是可以依照需求改變。

在前面的章節，我們的 run-on 都是直接借用 GitHub 提供的機器，因此不需要自行架設或是維護裝置，但是其實這個借用是有時間限制的，當額度用完的時候便無法繼續使用，因此如果是有較高頻率運行的夥伴可以考慮這個章節介紹的 GitHub Self-hosted runners，這個便是將 GitHub actions runners 架設在我們自行維護的機器上，如此一來就不需要跟 GitHub 借用機器了，因此是不會產生任何費用的，除了添購機器的成本啦。

為什麼選擇 Self-hosted Runners？

當我們使用 GitHub Actions 進行自動化工作流時，可以選擇 GitHub 提供的 GitHub-hosted runners 或自行架設的 Self-hosted runners。這兩者之間有何不同？為什麼我們需要考慮自行架設 Self-hosted runners 呢？

GitHub-hosted Runners 是由 GitHub 提供和管理的運行環境，預先配置了常見的工具和依賴項，因此用戶無需擔心基礎設施的配置和維護。然而，這些運行器有一些限制，如：

• 執行時間限制：每個工作流執行有時間限制，超過限制後將自動終止。
• 硬體資源限制：GitHub-hosted runners 共享硬體資源，這可能導致性能瓶頸。
• 軟體配置限制：由於環境是預配置的，無法完全自訂特定的工具或版本。

相對的，Self-hosted Runners 則是由用戶自行架設和管理的運行環境。這提供了更多的靈活性和控制，如：

• 無時間限制：我們可以根據需要設定執行時間，特別適合長時間運行的工作流。
• 專屬硬體資源：由於使用我們自己的硬體，因此可以確保工作流的性能，且不會受限於共享資源。
• 自訂環境：可以完全自訂運行環境，安裝特定版本的軟體或工具，滿足特殊需求。

Self-hosted Runners 使用限制

使用 Self-hosted Runners 時，有一些使用限制，可以參考以下條列：

• Job 執行時間：每個 Job 在 workflow 中最多可以執行 5 天。如果超過此時間限制，Job 將被終止並無法完成。
• workflow 運行時間：每個 workflow 運行時間上限為 35 天。如果達到此限制，工作流程將被取消。
• Job 排隊時間：Self-hosted Runners 的每個 Job 排隊超過 24 小時將會被取消，實際排隊時間最長可達 48 小時。如果在此時間內無法啟動，工作將被終止並無法完成。
• API 請求限制：每個 repository 內的 GitHub API 請求上限為每小時 1,000 次。如果超過此限制，額外的 API 請求將失敗，可能導致工作失敗。
• 工作矩陣限制：每次工作流程運行最多可生成 256 個工作，這適用於 GitHub 托管和自托管運行器。
• 工作流程排隊限制：每個 repository 在 10 秒內最多可排隊 500 個工作流程運行。如果超過此限制，工作流程將被終止並無法完成。
• 自托管運行器註冊限制：每個運行器群組最多可以註冊 10,000 個自托管運行器。如果達到此限制，將無法新增運行器。

這些限制在使用 GitHub Actions 時必須留意，以確保流程順利運行。

GitHub-hosted Runners 與 Self-hosted Runners 的比較

GitHub-hosted Runners 由 GitHub 提供並管理，適合快速啟動且無需自定義環境的工作，而 Self-hosted Runners 則允許使用者在自己的伺服器上執行工作，提供更多自定義與資源控制，但需要自行維護基礎設施。選擇哪種運行器應取決於專案需求及資源管理能力。

Self-hosted Runners 層級

GitHub Self-hosted runners 在架設上是有分層級的，分為以下三個層級：

• repository：專屬於特定 repository，只有該 repository 能跟調用該台裝置
• organization：這個層級的能夠提供給組織內多個 repository 使用，可以想像是在同一個 organization 裡頭的 repo 都可以呼叫到這台機器
• enterprise：在企業帳號中，可以將該台機器給予多個組織使用

關於詳細資訊可以參考官方文件：Adding self-hosted runners

安裝 GitHub Self-hosted Runners

在這個區塊我們來探討該如何安裝一個 GitHub Self-hosted Runners！不過是 repository 層級的，如果需要安裝另外兩個層級的，可以參考官方文件：Adding self-hosted runners，由於是要將 GitHub Self-hosted Runners 安裝在我們指定的電腦上，因此我們需要先準備一台電腦，後續的步驟為：

1. 開啟要安裝的 repository
2. 在 repository 名稱下方，點擊 Settings（設定）。如果無法看到 Settings tab 可以詢問 repository 權限的擁有者，是否是缺少權限
3. 在左側邊欄中，展開 Actions，然後點擊 Runners
4. 點擊 New self-hosted runner（新增自架設運行器）
   
5. 選擇要安裝的裝置的作業系統
6. 選擇 Architecture
7. 開啟終端機照著輸入 Download 及 Configure 裡的內容
   
8. 輸入完成後就成功拉！安裝過程相當的容易，設定好後便可以在畫面中看到目前的機器狀態，也可以開始在 workflow YAML 中也可以指定該設備了。
   

Github Action Secrets 機敏資料儲存

在 workflow 中，我們可能有時候會需要使用到機敏資料，像是第三方工具的金鑰匙，但是因為 workflow 的 yaml 是需要加入版控的，因此我們不可能直接將密碼裸露在 yaml 檔案中，這樣太赤裸危險了，所以我們可以將這些資料放在 GitHub Action 提供的 Secrets 中，方法如下：

• 在 GitHub repository 中，前往 Settings > Secrets and variables > Actions。
• 點擊 New repository secret，然後輸入名稱和對應的秘密值。
• 在 GitHub Actions 工作流程中，我們可以透過 ${{ secrets.SECRET_NAME }} 的格式來存取這些秘密。
  

在 workflow 的 log 中，GitHub 為了防止機敏資料被洩漏，在輸出時也會自動將機敏資料清除並用 * 號代替，同時在 Github Action Secrets 設定秘密後，即使點選修改也無法看到原先設定的值。

Github Action Secrets 命名規則

在 GitHub 命名 Secrets 時，必須遵守以下規則：

1. 名稱只能包含字母數字字符（[a-z]、[A-Z]、[0-9]）或底線（），不允許空格。
2. 名稱不能以 GITHUB 前綴開頭。
3. 名稱不能以數字開頭。
4. 名稱不區分大小寫。
5. 名稱在創建時必須是唯一的。

在 workflow 中使用 Github Action Secrets

我們可以透過 with 或是 env 的方式來抓取 secrets 的資料，當我們將 secrets 寫入 env 後，在 python 我們可以透過 os.getenv() 的方式將 secrets 讀取：

steps:
  - name: Hello world action
    with: # Set the secret as an input
      super_secret: ${{ secrets.SuperSecret }}
    env: # Or as an environment variable
      super_secret: ${{ secrets.SuperSecret }}

Github Action Secrets 限制

• 儲存上限：組織最多 1,000 個 Secrets，repository 和環境最多各 100 個 Secrets。
• 存取限制：工作流程最多可以使用 100 個 repository Secrets、100 個環境 Secrets，以及前 100 個組織 Secrets（按字母順序排序）。
• 大小限制：每個 Secrets 的大小限制為 48 KB，如果需要更大的 Secrets，可以參考官方文件。

關於 Github Action Secrets 更多詳細資訊，可以參考官方文件：Using secrets in GitHub Actions

結語

GitHub Self-hosted runners 提供了一種靈活且可擴展的 CI/CD 選項，特別適合需要高性能和自訂環境的專案。然而，這也意味著需要自行負責硬體維護和安全配置。透過了解其優勢與挑戰，我們可以更好的決定何時選擇 Self-hosted runners 作為團隊的 CI/CD 解決方案。

希望這篇文章能夠幫助到大家更深入了解 GitHub Self-hosted runners 的架設與應用。如果有任何問題或建議，歡迎在下方留言討論。