我一開始不相信這是真的，所以就調查了一下。 這是真的。實際上比乍看之下還要糟糕。這完全印證了 @ziglang 和 @theo 的說法，即 GitHub Actions 是一個令人惋惜、被忽視的平台。 接下來，讓我們一起來探索軟體考古吧…🧵
`safe_sleep` 是在 2022 年加入的。 它取代了 `sleep` 指令的使用。然而，`sleep` 是一個 POSIX 標準指令。 GitHub Actions 已經假定存在大量非 POSIX 指令，因此選擇這個腳本顯得有些奇怪。 https://t.co/imeOrBVdEc
它的實現方式非常明顯，幾乎任何人一眼就能看出它會一直佔用 100% 的 CPU，並且除非任務恰好在正確的時間檢查時間，否則它將一直運行下去。 https://t.co/dQPcUhYYsn
2024 年有人以平台無關的方式修復了 CPU 問題。但沒有人費心去審查或評論 PR。 https://t.co/ymPDlJLcF7
四月有人提交了一個問題，指出存在「無限休眠」的漏洞。 Guitar Heart 官方無人對此作出回應，該問題至今仍未解決。 https://t.co/ET43AKGzKy
同時，有人創建了一個 PR，計劃在 2024 年修復這個問題（但仍然存在 CPU 殺手循環）。一個月後，該 PR 自動關閉了。 今年八月，終於有人重新打開並合併了這個問題。 （但仍然沒有關閉該問題。） https://t.co/Qq2K2ORbsh
因此，實際使用了合理的睡眠實現的 PR 仍然沒有合併，而腳本目前仍然處於這種醜陋但勉強能用的狀態。 （另外，據我所知，企業是按 CPU 小時付費的。所以我猜這個小腳本對 GitHub 來說利潤很高…）
這一切的荒謬已經在開發者論壇上討論了一段時間，大家既感到困惑又感到恐懼。 https://t.co/wXF3Xh7li8
雖然有人可能會說這只是一起孤立事件，但我無法理解，在一個正常運作的組織中，怎麼會發生如此一系列令人瞠目結舌的事件。
我無法想像GitHub的創辦人看到他們一手打造的專案被如此冷落會感到高興。 😢
聽起來@ThePrimeagen也有同感…