掃描掛回 PR、草稿也跑 CI，並開始量覆蓋率 - #18
Merged
Merged
Conversation
CI 成本不再是判準（使用者裁示 2026-08-21，Enterprise 50k 分鐘／月）， 判準收斂成一句：CI 做得到的驗證，就讓它在合併前跑。 - security.yml：CodeQL／govulncheck／Trivy 各自那條 `if: github.event_name != 'pull_request'` 拆掉。2026-08-16 那個取捨的 前半仍然成立（這三種找到的東西是修一次就結束的），失效的是後半—— 省下的分鐘數值 0，而「在 main 才被攔下 ＝ 已經合併」的代價一直都在。 - ci.yml 的檔頭：草稿 PR 也跑 CI。舊註解寫著「草稿不跑（下面每個 job 的 if）」，而那個 if 十五個倉庫裡只有兩個真的有——十三個倉庫的草稿 PR 一直都在跑，註解描述的是一件沒有發生的事。那種錯不會自己被發現： 它的方向是「以為更省」，不會有帳單也不會有紅燈。 - 覆蓋率：量出來、報進 job summary、留成 artifact。在此之前十五個倉庫的 workflow 裡 -coverprofile 一次都沒有出現。刻意不設下限——當天量到的 十個 Go 倉庫是 42.5%～81.6%，一個統一的數字要嘛擋不住任何東西、 要嘛讓兩個倉庫從第一天起就紅。 決策見 workspace decisions/infrastructure/CI-成本不再是判準.md。
本倉庫**比其他倉庫更需要這一層，因為它是公開的**。內部服務出貨到 Debian 節點，平臺是我們自己決定的；這裡的使用者是誰、在什麼作業系統上編譯， 我們不知道。一個「只在 Linux 上成立」的假設，在這裡是**對外承諾的一部分**。 兩層各回答一個問題，**不得互相代替**（裁示 2026-08-22）： - **交叉編譯**（`Go SDK` job）——我能不能在開發環境裡建立生產執行檔？ 五個目標各 build ＋ vet 一遍。本倉庫先前**一個都沒有**。 - **目標平臺實跑**（新的 `platforms` job）——有沒有遺漏平臺特定語法 可能造成失敗？Windows 與 macOS 上真的 build／vet／test，Go 與 JS 都跑。 第一次跑就抓到兩個，兩個都只在 Windows 上成立： 1. **`logging` 斷言 log 檔是 0600**。NTFS 有 ACL、沒有 POSIX mode， 每個可寫檔案 `os.Stat` 都回 0666。照前例處置：講明那個保證在這個平臺上 不成立，不假裝通過。 2. **`lifecycle` 的測試用 `syscall.SIGUSR1`，Windows 沒有這個符號**—— 不是斷言紅，是**整個測試套件編不過**。拆成 `signal_unix_test.go` （`!windows`，內容一個位元組沒改）與 `signal_windows_test.go` （講明 Windows 為什麼送不出信號：沒有 SIGUSR1，而 `os.Process.Signal` 在那裡只支援 Kill）。 **Windows 那半刻意留一支會印出來的測試，而不是讓那個檔案在 Windows 上 不存在**——一個單純排除掉某平臺的測試套件，從那個平臺看過去， 跟一個通過的套件長得一模一樣。 驗證：五個目標 build ＋ vet 全過、Linux 全套測試綠、JS 33 項全過。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CI 方案升級之後，執行成本不再參與任何取捨。判準收斂成一句：CI 做得到的驗證，就讓它在合併前跑。 手動觸發只留給診斷與特殊組合。
改動
security.yml：三道「掃描不上 PR」閘門拆掉。 先前的理由是「這幾種掃描找到的東西是修一次就結束的，在 PR 攔下與在main攔下代價一樣，所以省下每個 PR 數分鐘」。那句話的前半仍然成立，後半不再是收益；而代價一直都在——一個在main才被攔下的問題，是一個已經合併的問題。草稿 PR 也跑 CI。 檔頭的註解先前寫著「草稿不跑（下面每個 job 的
if）」，而那個if在本倉庫根本不存在——草稿 PR 一直都在跑。註解描述的是一件沒有發生的事，而且方向是「以為更省」，所以不會有帳單、不會有紅燈、不會有任何人抱怨。現在條文與行為對上了，而且對的是「跑」那一邊。覆蓋率開始量（
go/），總數印進 job summary（附逐套件明細），profile 留成 artifact。刻意不設下限：一個憑空訂的數字要嘛擋不住任何東西、要嘛讓某些套件從第一天起就紅，而一個永遠紅著的檢查等於沒有檢查。修掉一段指著條文說自己不必照辦的註解。
securityjob 上方寫著「本倉庫是公開的，所以掃描與go、js同時起跑，不等它們綠燈」，並聲明「兩種形狀是刻意的，不是漂移」。那段文字從 2026-08-16 起就是錯的，而且取代它的needs:一直都在——就在同一個 job 裡下面幾行，還帶著自己的註解。沒有跟上的只有那段文字。這是最不容易被查的形狀：讀到的人會以為「這裡已經對照過了」，於是沒有人去對照。
零相依那條硬性規則不受影響：這一輪沒有動
go/go.mod與js/package.json，覆蓋率量測用的是 Go 內建的-coverprofile，沒有引入任何工具。本機驗證
go build／go vet／gofmt -l／go test -race四項綠，npm test綠，覆蓋率 81.6%（這一輪量到最高的一個）。