feat(deploy): 部署收尾刷新 current 連結農場
$JSC_HOME/current 是一組不帶版本的符號連結,每個外掛一條,指向快取裡帶版本號的實體目錄。技能文件裡所有跨外掛的腳本呼叫都以這一層為根,因為它不帶版本號、寫得進權限允許清單。 問題是沒有任何東西會更新這些連結,只有 wire-cli.sh 會更新 jsc-hooks 那一條。其餘幾條是人手動建的,建好之後就停在當時的版本。實際後果是部署完四個 domain 之後,快取裡是新版,連結卻還指著舊版:助理巡檢照文件的字面路徑跑,跑到的是舊腳本,而其中一個舊版底下根本沒有它要呼叫的檔案。失敗無聲,只有心跳停止,沒人盯就不會有人發現。 部署改成收尾時刷新整組連結。挑部署來做,是因為它本來就知道裝了哪些 domain、裝到哪個版本,資訊最齊。 四個設計決定: 基準 CLI 取 claude、codex、copilot、kiro 之中第一支找得到的,整輪只有那一支寫連結。連結農場只有一組,不可能同時指向五個 CLI 的副本;而五支 CLI 是平行跑的,五支都寫會互相覆寫,最後指到哪一份是隨機的、出事重現不出來。antigravity 一律不當基準,它的來源是本地 clone,而那份 clone 明文允許是維護者的開發樹,把全機器路徑指到做到一半的樹正好是這次要修的那種毛病。 版本目錄取版本排序最大、且真的有 plugin.json、且本身不是符號連結的那一層。要求 plugin.json 是因為裝到一半的目錄沒有它,挑到會讓連結指向不完整的外掛而且照樣不報錯。 解除安裝的判準是「連結還在、指向卻沒了」,不是「這輪解除安裝過這個 domain」。只解除安裝其中一支 CLI 時,連結可能還指著另一支手上完好的副本,那一條必須留著。 連結建立失敗印一行繼續,不記進失敗清單。這一段跑在外掛都裝好之後,部署本身已經成功;記成失敗會連帶跳過重啟閘門,操作者拿到的是一台明明裝好卻被說成失敗的機器。缺陷仍然看得見,因為輸出多了一行。 目標存在但不是符號連結時一律不覆寫,印 skip 要人工處理。ln -sfn 對著實體目錄下手會把連結建進那個目錄裡,農場當場壞掉還不會報錯。 新增 link 行讓呼叫端讀得到每一條連結指到哪裡,狀態五選一。技能文件與行為契約跟著更新,另修正一句因這次改動而失效的敘述:原本寫 current 底下沒有 jsc-cli,刷新之後那條連結會存在,改成講清楚它仍然靠不住,因為第一次建起它的正是這一輪。
This commit is contained in:
@@ -23,7 +23,7 @@ Marketplace 統一為 `jsc`(https://gitea.jsc.idv.tw/plugins/meta.git),安
|
||||
| 工具 | 用途 |
|
||||
| --- | --- |
|
||||
| `tools/detect-clis.sh` | 列出已安裝的 AI CLI 與執行檔路徑(TSV:name / path / version;antigravity 的執行檔為 `agy`、kiro 為 `kiro-cli`) |
|
||||
| `tools/deploy.sh` | 對單一 CLI 執行安裝、更新或解除安裝(`deploy.sh [-n] {mode} {cli} {domain}...`,mode 為 install / update / uninstall);印出每個指令與其結束碼,最後一行 `result` 標 ok 或 fail。`-n` 只印指令不執行。上表五個 CLI 的指令差異全部收在這支腳本裡。Codex 更新 `jsc-cli` 與 `jsc-hooks` 後會把舊版快取路徑補成指向新版的相容連結,避免正在跑的部署流程找不到 helper 腳本,也避免尚未重啟的工作階段在 Stop hook 階段找不到舊路徑。install 或 update 全數成功時,收尾轉呼叫 `jsc-hooks` 的 `restart-gate.sh require` 掛上重啟閘門,並印一行 `restart` 標出狀態檔位置;uninstall 不寫。尋找 `restart-gate.sh` 時優先用 `$JSC_HOME/current/jsc-hooks`、本地 clone 與 Kiro skills,最後才掃各 CLI 快取,避免部署收尾綁死單一 CLI 的版號路徑。狀態檔的路徑、格式與判讀全在 `restart-gate.sh`,這支腳本不自己拼——格式只留一個真實來源。站台取自 `GITEA_HOST`,本地 clone 目錄取自 `JSC_LOCAL_PLUGINS`,兩者的預設值見下表 |
|
||||
| `tools/deploy.sh` | 對單一 CLI 執行安裝、更新或解除安裝(`deploy.sh [-n] {mode} {cli} {domain}...`,mode 為 install / update / uninstall);印出每個指令與其結束碼,最後一行 `result` 標 ok 或 fail。`-n` 只印指令不執行。上表五個 CLI 的指令差異全部收在這支腳本裡。Codex 更新 `jsc-cli` 與 `jsc-hooks` 後會把舊版快取路徑補成指向新版的相容連結,避免正在跑的部署流程找不到 helper 腳本,也避免尚未重啟的工作階段在 Stop hook 階段找不到舊路徑。收尾還會刷新 `$JSC_HOME/current/` 那一組不帶版本號的符號連結(技能文件的跨外掛路徑都以那一層當根):install 與 update 把每一條指到這次裝的版本目錄,uninstall 清掉指向已消失的那幾條,一條印一行 `link`,第五欄就是指向。一台機器只有一組農場,所以只有基準 CLI 那一輪會動它,基準取 claude、codex、copilot、kiro 之中第一支裝得到的;連結刷新失敗只記一行、不讓部署變成失敗。install 或 update 全數成功時,收尾轉呼叫 `jsc-hooks` 的 `restart-gate.sh require` 掛上重啟閘門,並印一行 `restart` 標出狀態檔位置;uninstall 不寫。尋找 `restart-gate.sh` 時優先用 `$JSC_HOME/current/jsc-hooks`、本地 clone 與 Kiro skills,最後才掃各 CLI 快取,避免部署收尾綁死單一 CLI 的版號路徑。狀態檔的路徑、格式與判讀全在 `restart-gate.sh`,這支腳本不自己拼——格式只留一個真實來源。站台取自 `GITEA_HOST`,本地 clone 目錄取自 `JSC_LOCAL_PLUGINS`,兩者的預設值見下表 |
|
||||
| `tools/check-requires.sh` | `check-requires.sh {cli} {manifest}` 檢查 manifest 的 `jsc.requires` 最低版本。沒有宣告就通過;版本不符或缺相依 plugin 就回 `status=blocked` 與結束碼 1。`deploy.sh update` 在每個 domain 更新前呼叫它一次:結束碼 1 只印一行 `warn`,那個 domain 照樣更新——跳過會讓落後的 domain 永遠等不到相依版本,也就永遠更新不到,真正的阻擋由 `jsc-hooks` 的 `version-guard.sh` 在技能被叫用時執行;結束碼 2 以上是檢查腳本自己出錯,讀不到結論就不當成通過,印 `skip` 並跳過該 domain |
|
||||
| `tools/write-guides.sh` | 產生這台機器專屬的更新指引 `$JSC_HOME/update-guide.md` 與移除指引 `$JSC_HOME/remove-guide.md`(`write-guides.sh [-n] {install\|update} {domain}...`),一輪部署跑一次。CLI 清單取自 `detect-clis.sh`,每支 CLI 的指令字面直接取自 `deploy.sh -n` 的輸出,所以指引寫的就是實際會跑的指令;kiro 走不走本地複製退路也依實際偵測結果標注 |
|
||||
| `tools/list-models.sh` | 讀各 CLI 設定檔列出模型(TSV:cli / model / in-use);設定檔缺失就不輸出該 CLI 的列,一律 exit 0。設定檔位置只寫在這支腳本裡 |
|
||||
|
||||
Reference in New Issue
Block a user