在前面幾篇文章實作 GitHub Action Workflow,眼尖的讀者應該會發現,我們使用是 GitHub 所提供的 Runner,我們只需指定作業系統版本、SDK 即可,不需要自行維護作業系統、網路與安裝其他程式,其餘的工作皆依據 workflow 定義的去執行。缺點在於若不是 public repo,會有使用時間上的限制。理所當然,倘若公司或開發人員本身就擁有伺服器或虛擬機器,也可以使用自己的機器作為 Runner,除了不需要額外費用,也能高度自訂專屬的自動化流程,。
這種使用自己環境作為 Runner,我們稱之為 Self-hosted runners
如果 Self-hosted runners 超過 30 天未連接到 GitHub Action,則會自動從 GitHub 中刪除。
建議使用 Self-hosted runners 在 private repo,因為你不知道你 Fork 的 repo 是否有埋藏惡意程式
Self-hosted runners 維護上較為麻煩,除了作業系統,建置專案時所用的 SDK 也需要自行安裝,如 Build Tools for Visual Studio, JDK, Android SDK...等
Self-hosted runners 從管理層面來看,可以分成三類
可以作為 Self-hosted runners 的作業系統如下
選擇你的作業系統,你能發現,下方已經將安裝與設定語法提供給你,只需要複製語法,在自己的環境貼上即可
我們實際行下載指令
注意:當你執行 Invoke-WebRequest -Uri https://github.com/act... 若出現下列錯誤
請輸入:[Net.ServicePointManager]::SecurityProtocol = "tls12, tls11, tls"
接下來我們進行設定,依序會回答一些問題,包含 Runner Group, Runner 名稱(預設伺服器名稱)、Label 、工作資料夾、是否註冊成服務(建議選Y),服務的帳號...等
完成後,回到 GitHub Repo Runners 畫面,即可看見已經連結的 Runners
若你要移除這個 Runner 之需要透過下列指令移除即可./config.cmd --url [repo url] --token [xxx] remove
若你的 workflow 要使用這個 Self-hosted runner,只需要找到 runs-on,加上你前面設定 runner 時使用的label,依據我們的案例,改成 self-hosted 即可runs-on: self-hosted
閱讀完這篇文章,你會發現加入 Self-hosted runners 其實不難。但實際上在企業、組織中共用 Runner,要安裝那些套件、如何維護才是讓人頭痛。在下一篇文章,我們將介紹 Runner 的另一種應用: 常見代理程式架構與部署至 IIS。
若喜歡我的文章,歡迎點 like, 分享與訂閱。
https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners