本篇文章更新時間：2026/01/15
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
我討厭 GitHub Actions 的日常：一場被 CI 綁架的開發者心聲
編輯前言：這篇文章來自作者對 GitHub Actions 的真實怒吼，標題直白到不需要翻譯。作為讀者，我覺得它值得一讀，因為它揭露了每個開發者多少都曾遇過、卻懸而未決的 CI 痛點。
來源文章：I Hate Github Actions with Passion
核心觀點 (Key Takeaways)
- GitHub Actions 在跨平台建置上常常表現不一致，而這種細微差異會無限放大開發者的痛苦。
- CI 的回饋迴圈太慢，任何小修改都要等數分鐘，嚴重降低工作流效率。
- 最好的做法是「不要把邏輯綁在 Actions 裡」，能在本地掌控的就不要交給 CI 系統。
深入解析
作者原本只是在替自己的專案 tmplr 實作 build.rs，透過 CUE 產生 README、CHANGELOG 等文件。這在本地測試一切運作良好，但一推上 CI 就出事了：Linux ARM 的建置直接找不到 CUE。
引用一句原文的嘆息：
“Thank you GitHub Actions. What would’ve I done without you.”
問題的根源其實不複雜：GitHub 的跨平台 matrix runner 隔離得非常徹底，以至於某些平台會直接「看不到」原本安裝好的二進位檔。於是 macOS 和 Linux x86_64 都能跑 CUE，偏偏 Linux ARM 完全無法。
結果就是那個所有人都深惡痛絕的迴圈：
- 改 CI 文件
- 推 commit
- 等跑 Actions
- 點開對應平台的 log
- 看它失敗
- 憤怒
- 重來
作者形容這流程就像 2026 年的你還在用軟碟儲存或用蝸牛郵件下棋。雖然誇張，但很貼切。
最後作者受不了，把所有 build 邏輯搬回 Makefile，本地產生好檔案後直接 commit，CI 不再負責這些步驟。這個策略讓他脫離苦海，也符合一句網路智慧名言：
“Don’t let GitHub Actions manage your logic. Keep your scripts under your own control.”
筆者心得與啟發
讀完這篇，我最有感的是 CI/CD 工具其實是一把雙面刃。一方面，它能提供便利的自動化與跨平台環境；另一方面，只要環境稍有差異，開發者立刻掉進無止境的 debug 地獄。
作者的做法提醒我一件事：
把能穩定、可複製、可控的邏輯放回專案內，而不是寄望在 CI 上發生魔法。
特別是那些一旦失敗就需要三分鐘才能看到結果的流程，更該盡量前置到本地完成。
如果你也在被 GitHub Actions 折磨，或許可以從這篇文章得到某種釋放：不是只有你覺得痛，而是很多人都痛，只是有人比較誠實地講出來。