凌晨11點,你推送了那行"應該是最后一次"的提交。GitHub Actions開始運行。紅色叉號。
你點進工作流日志。4000行輸出。真正的錯誤藏在npm安裝提示、棄用警告,以及那個莫名其妙重試兩次的任務之間。20分鐘后你找到了:一個缺失的環境變量。或者一個 flaky test。或者某個特定任務里的Node版本不匹配。
![]()
這個循環太熟悉了。FailBrief的誕生,就是因為有人厭倦了這種循環。
這是一款GitHub App,專門監控Actions工作流。當構建失敗時,它會做一件人類有無限耐心才會做的事:讀完日志,找出問題,用 plain English 寫一條評論——直接出現在你的PR頁面。
評論里包含錯誤類型、嚴重程度、具體出錯的代碼行,以及建議修復方案。它出現在你本來就要看的地方。
最初以為這只是個"讀日志、解釋日志"的單功能工具。但團隊想要更多。
Flaky test 檢測。你知道那種測試:本地通過,CI失敗,重試又通過,周二又失敗。FailBrief追蹤多次運行的通過/失敗模式,標記統計上不可靠的測試,給出 flaky 分數和可能原因(時序、異步、共享狀態等)。大多數CI工具完全忽略 flaky 測試。它們不應該。
一個儀表盤,追蹤每個倉庫的健康分數、失敗趨勢、MTTR(平均修復時間)、最常見的錯誤類別。用來回答那個"我們的CI到底怎么樣"的問題——這個問題原本出奇地難回答。
Slack和Discord通知。有些團隊希望失敗被主動推送,而不僅僅是評論。
倉庫健康評分。一個數字告訴你:這個倉庫的CI是狀態良好,還是在默默著火。
目標用戶很明確:個人開發者,或2-50人的中小團隊,使用GitHub Actions。開源維護者尤其如此——盯著貢獻者的失敗CI運行,反復解釋同樣的五種錯誤,是一種已知的痛苦形式。
500人的工程組織,有專門的平臺團隊和自定義日志解析器?你們大概有自己的方案。
FailBrief不是什么:它不是完全替代人工調試的工具,不能修復所有CI問題,也不是企業級可觀測性平臺。但它是一雙可靠的第二雙眼睛,永遠不會累,永遠不會在凌晨11點翻4000行日志。
安裝很簡單:GitHub App,選擇倉庫,完成。沒有配置文件,沒有工作流改動,沒有YAML要編輯。免費版每月25次分析,跨無限倉庫,足夠大多數小項目驗證是否有用。
目前有早鳥碼(EARLYBIRDCODE),前100名用戶可免費使用3個月Pro計劃:500次分析、高級AI、Slack/Discord集成。地址是failbrief.com。
如果試了發現它漏掉了明顯的東西,告訴開發者。比起默默卸載,他們更愿意聽到"你們的AI對Rust構建錯誤很蠢"。評論、提issue,都可以。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.