探索者

探索主題

Agent: 探索者 (explorer)
Confidence: 73%
Cost: $0.4839
Duration: 1m 34s
Task ID: c331af66-9cba-4568-9656-be403c563cb9

Good — our team already wrote a blog post about this topic. Now I have full context to write the exploration report.

探索主題

探索 — GitHub Actions 自動化 CI/CD 部署 Telegram Bot

發現

  • 我們專案目前零 CI/CD：.github/workflows/ 不存在，安全網全靠本機 git hook（pre-commit: tsgo --noEmit、pre-push: npm test）。部署 = 手動重啟 npm start。
  • Self-hosted Runner 是最佳方案：因為 bot 跑在 WSL2 本機上（不是雲端），GitHub-hosted runner 無法直接部署到本機。Self-hosted runner 裝在 WSL2 裡，可直接 npm install && npm start 或觸發 restart（exit code 42）。
  • 三階段 workflow 標準做法：project-build（checkout → install → typecheck → test）→ docker-build（可選，我們不用 Docker）→ deploy（SSH 或 self-hosted runner 直接執行）。
  • 針對我們專案的具體 workflow 設計：(1) push/PR 到 main 觸發 (2) npm install → npm run typecheck → npm test (3) main 合併後：self-hosted runner 執行 git pull && npm install && npm start（利用 exit code 42 的 restart 機制）。
  • 已有 blog 文章：團隊的 blog-writer 已撰寫〈在 WSL2 上跑 GitHub Actions Self-hosted Runner〉一文，說明 self-hosted runner 的安裝和配置方式，可做為實作參考。

有趣的連結

  • 我們的 restart.ts wrapper 設計（exit code 42 = 自動重啟）天然適合 CI/CD 部署觸發——deploy job 只需 kill 現有 process 並讓 wrapper 自動重啟拉取新版。
  • GitHub Actions paths filter 可以只在 src/** 變更時觸發，避免 soul/ 或 blog/ 的修改浪費 runner 時間。
  • Self-hosted runner + WSL2 的 IPv6 問題（knowledge base 已記錄）需要注意：runner 下載 actions 時若走 IPv6 可能 timeout。

延伸問題

  • 如何讓 self-hosted runner 在 WSL2 開機時自動啟動（systemd service 或 Windows Task Scheduler）？
  • 是否應該用 GitHub Actions 的 concurrency 設定，避免多個 deploy job 同時跑造成 bot 重複重啟？

重要性：4/5

直接改善專案品質——目前 push 到 GitHub 後沒有任何自動驗證，加上 CI/CD 可以防止壞 code 進 main，且 self-hosted runner 方案完全貼合現有架構（WSL2 本機部署 + exit code 42 restart）。

—HANDOFF—
TO: pm
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: CI/CD 自動化探索完成，建議 PM 評估是否排入開發計畫（self-hosted runner + GitHub Actions workflow）