北京
你有沒有盯著CI管道上的一排綠色對勾松了一口氣，點擊“合并”，然后幾小時后被同事告知“發布的東西不對”？我有。而且，是兩次，在同一條發布管道上。
起因很簡單：我用 python-semantic-release 搭了自動發布流程，提交規范用約定式提交，工具自動判斷版本號、打標簽、推送改動。為了讓發布任務能向受保護分支推送版本號和更新日志，我特意配置了一個擁有寫入權限的 RELEASE_TOKEN。接好管線后，推送代碼，管道運行，綠色對勾亮起，一切看起來順理成章。
第一個坑，來自 python-semantic-release 的“體貼”短路。它只在最近一次標簽之后的提交中包含 feat 或 fix 類型的 commit 時，才會執行真正的發布動作。而我的兩次“綠色運行”，碰上的提交類型分別是 docs（文檔）和 ci（CI配置）。工具掃了一眼，判斷沒有任何需要發布的內容，于是提前退出，并返回 0。RELEASE_TOKEN 沒用到，保護分支推送沒執行，標簽也沒打——整個過程最關鍵的推送到保護分支這一步，根本沒被測試。綠色對勾的意思是“沒有可發布的內容，所以我什么都不做，并且我成功做到了”。
第二個坑，藏在構建命令的默認行為里。管道里有一個 build_command 負責在發布前生成構建產物。問題是，它只運行你給的命令，不會自動把命令產生的文件納入暫存區。如果你緊接著提交并推送，那些剛生成的產物根本不會出現在提交中，除非你自己顯式去做 git add。每個單獨的任務都綠著：build 命令退出 0，release 步驟退出 0。只有當把目光拉到整個分支的差異上，去看真正會被發布的文件時，才發現產物集體缺席。
兩次事故，同一個根源：綠色對勾只報告你讓系統運行的命令的退出碼，它檢測不了你心里假設命令會做完的事。覆蓋率不等于正確性。持續集成管道只驗證你編碼進去的路徑，而且用的是你恰好喂給它的輸入。最容易崩的，正是那些從未被充分演練過的路徑——被 mock 掉的集成、只存在于生產環境的配置、當前提交恰好觸發不到的邏輯分支。
“所有檢查通過”和“發布能正常工作”是兩碼事，管道只能證明前者。現在我改掉了習慣：去看日志，而不是盯徽章。在相信一個綠色的發布之前，我會確認具體要走的路徑確實跑完了。綠勾只是告訴你退出碼為零，至于你真正關心的邏輯有沒有執行到，得自己翻。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
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.
