開發者 bestony 前幾天在 V2EX 分享了一個開源專案 self-hosted-action-runner。他的起點很實際：程式碼放在 GitHub 上，CI/CD 自然用 GitHub Actions，但自從把 AI 加進工作流程，GitHub Pro 每月送的 3000 分鐘構建時間開始不夠用，於是他動手把 Actions Runner 容器化，做出一鍵自建方案，還支援本地快取加速。

這類技術分享我們看過不少，像之前聊過的工程師開源 FTP 連接池 TidePool 的故事一樣，工具背後總有一個熬夜解決問題的人。這次換個角度，聊聊「等構建」這件事，對你的身體意味著什麼。

這個專案解決了什麼

根據作者的分享，市面上現成的 self-hosted runner 方案，要嘛是對單機和小團隊來說太沉重的 K8s Operator，要嘛只是簡單的 Dockerfile，沒考慮持久化和多倉庫需求。所以他的設計重點包括：

  • 用 DooD 模式掛載宿主機的 docker.sock，工作流裡的 docker build、container: 都能照常跑，宿主機只需要裝 Docker
  • 憑據和配置存在獨立卷中，容器重啟或升級重建後，不需要回 GitHub 頁面重新申請 Token 註冊
  • 給 Runner 的二進位檔打了補丁，讓原生的 actions/cache 不用改任何 YAML，就自動走內網自建的 Cache Server
  • 在 .env 填 RUNNER_EXTRA_APT_PACKAGES，重啟就能補齊缺少的系統依賴，不必為了幾個套件天天重建鏡像
  • 一行互動式腳本，一臺伺服器可以混配多個組織和倉庫，按需分配實例數

安裝方式是一行 curl 腳本。這裡照慣例提醒一句：把任何安裝腳本管線導向 bash 之前，先打開腳本看一眼內容，是你對自己機器的基本照顧。另外討論串裡有網友提出，公共儲存庫的 Action 用量本來計費方式就不同，實際能省多少，建議對照 GitHub 官方的計費文件確認，這部分分享內容沒有展開。

等構建的時間，你都在做什麼

真正想聊的是這個：3000 分鐘不夠用，背後通常是構建排隊、工作流卡住的等待時間。等待的時候，很多人會陷入兩種模式。

一種是盯著進度頁面不放，眼睛持續盯著螢幕，脖子前傾，肩膀聳著，十分鐘過去才發現自己沒換過姿勢。另一種是切去別的分頁「順便滑一下」，等構建跑完，半小時已經消失在資訊流裡，正事沒推進，疲勞倒是累積了。

如果你也常卡在這種節奏裡，可以參考我們之前寫過的被推送淹沒的工程師找回注意力的方法，把「等結果」和「看結果」分開：讓通知告訴你構建好了，而不是你的眼睛負責輪詢。

幾個順手能做到的調整：

  • 構建超過五分鐘就離開座位，裝水、伸展肩頸，讓眼睛看六公尺外的東西，睫狀肌（眼睛裡負責對焦的小肌肉）才有機會放鬆
  • 會自我安慰的排隊心理其實有用：把等待視為強制休息，而不是浪費的時間
  • 深夜跑長工作流時，設定完成通知就去睡，別為了看綠燈亮起而延後就寢

把工具裝好，也把自己照顧好

作者的目標是把 Runner 做成乾淨、免運維、可直接複製升級的容器，這個思路很對：能自動化的事情就交給機器。同樣的道理放到身體上也成立，與其靠意志力記得休息，不如讓環境幫你，例如把螢幕通知、定時提醒當成你的「健康 CI」。

自建 Runner 省下的是帳單額度和排隊時間，這些時間能不能變成你的休息時間，而不是又一輪滑手機的時間，才是工具升級之後真正值得想的事。

這則分享出自 V2EX 的分享創作版，專案放在 GitHub 上，有興趣實際動手的人，使用前記得閱讀專案文件與授權條款。