今天，我們會進一步探討 GitHub Actions 中 Runner 的角色以及它是如何執行任務的，並會著重在Self-Hosted Runner與GitHub-Hosted Runner之間的區別，這跟錢有關係。

Runner的基本概念

Runner是GitHub Actions中用於執行CI/CD工作流程（workflows）的一個程式，存在於虛擬機或實體機、也可以編譯成一個 container 活在隔離環境內。當您推送代碼或觸發其他 GitHub 事件時，Runner 會接收這些指令並開始執行預定義的任務，例如代碼編譯、測試運行，或者部署應用程式。

Self-Hosted Runner 與 GitHub-Hosted Runner 各有優缺

這個執行 CI/CD 流程的程式你可以自己架，也可以用 GitHub 提供的，只要能符合需求都可以，但它們還是有些微妙的區別：

Self-Hosted Runner

1. 自有環境：這些 Runner 運行在您自己的機器上，無論是實體還是虛擬。
2. 更多控制：更大的自由度來控制硬體、操作系統或安裝的軟體。
3. 網路存取：存取地端的資源、或是在地端部署應用程式，這在 GitHub-Hosted Runner 雖然是可能的，但須要做額外的設定，如 site-to-site VPN (搭配 Azure VNET)，並且會需要使用 larger runner。會有這種需求的人基本上得去訂閱 GitHub Enterprise Cloud，但我覺得改用地端的 CI/CD 方案可能還比較快，或是乾脆架設 GitLab 吧...
4. 成本：需要自己承擔硬體和維護成本。
5. 安全性：source code 都丟雲端了還考慮安全性嘛...

GitHub-Hosted Runner

1. 零配置：無需自己維護和更新 Runner，GitHub 會在執行 workflow 時產生一個新的 VM 給你跑 CI/CD。
2. 多平台支持：支持多種操作系統，包括 Windows、macOS 和 Linux。
3. 限制：硬體資源和運行時間有一定的限制，付費可以解鎖。
4. 成本：可能會產生一些額外費用，比如你要存取地端的資源的話就要額外付出 VPN 建立費用還有 larger runner 的費用。

執行任務的方式

Runner接收到工作流程後，會依據 .github/workflows/main.yml 或其他工作流程文件中定義的步驟（steps）來執行任務。這些任務通常會包括以下階段：

1. 初始化：Runner 預備執行環境，如拉取代碼。
2. 執行：運行定義的每一個步驟，這可能包括編譯、測試和部署。
3. 清理：工作完成後，Runner 會清理環境以準備執行下一個工作。