走通腳本契約:共用函式庫、四層前置檢查與 labels-list #3
Notifications
Due Date
No due date set.
Blocks
Depends on
#4 以 sdlc-plan 把口語需求轉成結構化需求議題
plugins/tea-sdlc
#16 以 sdlc-report 產出工時報表
plugins/tea-sdlc
#2 把模板 scaffold 換成 tea-sdlc 骨架
plugins/tea-sdlc
Reference: plugins/tea-sdlc#3
Reference in New Issue
Block a user
母議題
#1 — tea-sdlc:以 tea 驅動 SDLC 全流程的跨平台指令組
要做出什麼
讓第一支腳本從頭到尾跑通,把所有腳本共用的契約一次立好。
使用者在終端執行一支讀取型腳本,拿到單行 JSON;若環境有問題,得到的是一個明確的錯誤碼與「該去哪裡改設定」的指示,而不是後續步驟東一個西一個地失敗。
前置檢查涵蓋四層:執行環境(node/git/tea 是否存在)、Gitea 登入是否有效、帳號對目標 repo 的 issues unit 是否有寫入權、repo 是否已開啟時間追蹤。第三層必須針對 issues unit 實測,不能只看
permissions.push——team 的 unit 權限可以獨立於 repo 的 push 權限。同時把測試要用的隔離手法立起來:Gitea 呼叫集中在單一函式,測試時指向本機 stub server 錄放請求;git 操作集中在單一執行點,測試在臨時 repo 上跑真實 git。這套手法之後每一支腳本都會沿用。
腳本定位
templates/與references/一律從自身檔案位置回推 plugin 根,不依賴 cwd 或環境變數。驗收標準
--dry-run、冪等查重、單行 JSON 輸出{ok, data, error:{code, message}},輸入一律具名 flaglabels-list可列出目標 repo 的既有標籤,且不具備建立標籤的能力templates/與references/,在任意 cwd 下執行結果相同阻擋於
由 PR #20 完成並已合併進 master。該 PR 的 commit 訊息漏了
Closes #3,因此未自動關閉,這裡手動補上。