status 加 --verdict,把狀態與成敗兩種語意分開 #86
1 Participants
Notifications
Due Date
No due date set.
Blocks
#77 唯讀盤點那一欄補一條結束碼規則,並換掉一個用結束碼帶狀態的指令
plugins/meta
Reference: plugins/hooks#86
Reference in New Issue
Block a user
摘要
wire-cli.sh status的結束碼帶的是狀態。於是有先天限制的那一支 CLI 每一輪讓那一筆失敗一次、一天 96 次,而沒有人修得動。這張把兩種語意分開。變更內容
tools/wire-cli.shstatus加--verdict旗標;用法說明與結束碼表各補一段同一個通道,兩種意思
wire-cli.sh statusstatus的三分法本身沒有錯,它是給人看的盤點。錯的是拿它當檢查。而那一支自己分得很清楚:
degraded是「該接的都接了,這支 CLI 做不到」,unwired才是「有東西沒接」。前者是狀態,後者是缺陷。 讀的那一邊把兩者都當失敗。這個計數為什麼不能被填滿
失敗次數存在的理由是指出「有一筆壞掉的項目每輪重試而沒人知道」。
那支 CLI 擋不下技能叫用是它的架構限制——技能走的是 agent 內部請求,攔不到;16 個接線項目全部就位,沒有東西要修。被一個修不動的數字每天加 96 次,就等於用假的壞掉把真的壞掉蓋掉。
為什麼修在這一邊
狀態與成敗是兩種語意,混在同一個通道上才是根因。
另一條路是讓讀的那一邊認「可接受的非零碼」——那要在待辦簿加一個欄位,而且每個往後填那一欄的人都得先想「我的結束碼是哪一種語意」。修在這裡只需要知道自己的三種狀態哪一種是缺陷,而那個知識本來就在這一支裡。
旗標的行為
--verdict之下輸出一字不變——degraded那一行照印,人看得到——只有結束碼換一套語意:statusstatus --verdict只有
status收這個旗標,別的子命令帶了回 2:另外三個子命令的結束碼本來就是成敗語意,多一個旗標只會讓人以為它們也有兩套。測試結果
diff無輸出),status=degraded那一行照印。--verdict回 5,還原後回 0。缺陷那一路沒有被放寬。lint-scripts.sh、check-behaviors.sh、ste100-lint.sh三支都回結束碼 0。相關的另一張
plugins/meta那邊同時把委派清單那一格換成帶旗標的寫法,並在那一欄的檔頭補一條規則:結束碼只准表示過與不過,不准用來編碼狀態。 那是這一次真正缺的規則,兩張都合併之後才完整。前置 Push Request