我一开始不相信这是真的，所以就调查了一下。 这是真的。实际上比乍一看还要糟糕。这完全印证了 @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也有同感……