develop
master
git clone
跨外掛路徑解析改實體解析(jsc_abs_path 與 jsc_gitea_sh),修好完全失效的版本閘門;接線腳本的 HERE 與 ROOT 改實體解析,讓共用連結不再可能被寫成指向自己;行為契約第 10 列跟著調整。
jsc_abs_path
jsc_gitea_sh
HERE
ROOT
lint-scripts.sh
check-behaviors.sh
ste100-lint.sh
版本閘門對 11 個 domain 全部回「查詢失敗」,等於完全失效——它擋不下任何版本落後的技能呼叫,而且是無聲的:report 照印表格,只是每一列都寫查詢失敗。 根因是 jsc_gitea_sh 回傳的路徑帶著 ..,而那些 .. 要穿過 current/jsc-hooks 這條符號連結。兩種解析方式對它的答案不同:核心與 [ -f ] 用實體解析、跟著連結走,判定檔案存在;shell 的 cd 用邏輯解析、純文字消去 ..,落到一個不存在的目錄。所以 [ -f ] 檢查通過、路徑交了出去,gitea.sh 的 cd 卻失敗,回結束碼 2 與空輸出,呼叫端就判成查不到。 新增 jsc_abs_path,用 cd -P 加 pwd -P 把路徑正規化成不含 .. 的實體路徑。挑這個做法是因為兩者都是 shell 內建,不必在 PATH 上找執行檔——這些函式會在 cron 那種只剩幾段 PATH 的環境下跑,少一個外部相依就少一個解不出來的理由。jsc_gitea_sh 的四條候選改成尾端統一正規化,正規化失敗就退回原樣路徑,「找得到」的判準不變。 wire-cli.sh 的 HERE 與 ROOT 一併改成實體解析。那是同一個根因的另一種發作方式:ROOT 會被 ln -sfn 當成目標,而這支腳本常常就是經由那條連結被叫起來的,邏輯解析會讓 ROOT 等於連結自己,連結被改成指向自己,全機器 hook 一起失效。這件事實際發生過。原本靠兩道防線擋著:事後的 [ -f ] 檢查,以及文件要求呼叫端先解出實體根目錄。前者要等連結已經被寫壞才攔得到,後者靠人記得。改成實體解析之後這個失敗模式不可能成立。 行為契約第 10 列跟著改:從實體根目錄跑 wire-cli.sh 的規定保留,但性質從必要條件降成多一層保險,並寫明保險為什麼還值得買——舊版腳本還在別的機器上跑。 驗證用同形佈局做:暫存區搭一套一樣形狀的連結農場,先塞原版重現失敗、再塞改版確認修好。真實環境的連結與快取全程沒有動過。
路徑解析的修正要靠版號才傳得到機器端,版本前置檢查才會要求更新。 三份 manifest 由 sync-skill-manifest.sh 同步,只動版本欄位。
Reviewed-on: #82
No dependencies set.
The note is not visible to the blocked user.
摘要
develop的路徑解析修正釋出到master。部署工具的git clone沒有指定分支,抓的是預設分支master,所以變更沒進master就到不了任何一台機器。版本 0.4.2 升到 0.4.3。變更內容
跨外掛路徑解析改實體解析(
jsc_abs_path與jsc_gitea_sh),修好完全失效的版本閘門;接線腳本的HERE與ROOT改實體解析,讓共用連結不再可能被寫成指向自己;行為契約第 10 列跟著調整。設計重點
develop的變更,這裡不新增任何程式碼。develop的驗證是在同形佈局與 dry-run 做的,真機驗收要等部署。測試結果
lint-scripts.sh、check-behaviors.sh、ste100-lint.sh。前置 Push Request