發佈 jsc-sdlc 0.1.1:PR 未合併不開下一包、檢查時讀留言 #16
2 Participants
Notifications
Due Date
No due date set.
Depends on
#16 發佈 jsc-gitea 0.1.0:新增 pr-status 與 pr-comments
plugins/gitea
Reference: plugins/sdlc#16
Reference in New Issue
Block a user
變更摘要
PR 建立後就停住:該 PR 沒合併之前不得開始下一個工作包。每次檢查 PR 是否完成時,順便讀留言並詢問使用者要不要依留言修正。
流程
implement新增步驟 4「先處理上一個工作包的 PR」,排在挑選工作包之前:gitea.sh pr-status {owner}/{repo} {index}。merged=true→ 解除阻擋:移除該包的 worktree、把工作包標記完成、繼續。gitea.sh pr-comments回傳 issue 留言、審查評語、行內程式碼留言,依時間排序,原文轉述給使用者(作者、時間、內容)。步驟 11 相應改為:建立 PR → 把 PR 連結寫進分析頁的 PR 欄 → 保留 worktree → 回報 PR 網址並停止,不開下一包。
推翻了先前的一個決定
worktree 的移除時機從「PR 建立成功後」改為「PR 合併之後」。
這不是偏好問題:新規則要求「留言要求修改時回去改」,而修改要回到同一個 worktree、推到同一條工作分支。PR 一建立就移除 worktree,等於每次收到留言都要為了改一行重建整個 worktree。
分析頁樣板
WBS 表新增 PR 欄,記錄該工作包的 PR 連結與編號。這是下一次執行
implement時找得到「上一包的 PR」的唯一途徑——沒有它,步驟 4 無從查起。新增的工具(jsc-gitea,另一個 PR,本 PR 依賴它)
gitea.sh pr-status <owner>/<repo> <index>{state} {merged} {mergeable}gitea.sh pr-comments <owner>/<repo> <index>驗證
pr-status與pr-comments都在真實 PR 上實測過。過程中發現一件事:Gitea 的 PRcomments計數會把沒有文字的審查算進去,只印有內文的留言會讓APPROVED/REQUEST_CHANGES這種關鍵狀態完全消失。pr-comments因此改為無評語的審查也照印,標成「(無評語)」。STE100 lint 通過;description 5 句;步驟編號 1~13 連續。