feat(ai-code-review): 建問題模式導向 issue,並整併流程調整、文件與 CI #17
Notifications
Due Date
No due date set.
Blocks
#6 feat(ai-code-review): 建問題模式導向 issue,並整併流程調整、文件與 CI
node-actions/ai-code-review
Reference: node-actions/ai-code-review#17
Reference in New Issue
Block a user
變更摘要
本 PR 將 ai-code-review action 分支的完整成果併入
develop,主要含四塊:create-issue: 'true'時,審查留言(工具/diff/角色/嚴重問題/警告+建議)全部改發到追蹤 issue、不再張貼到 PR;不執行「舊留言標過時/resolve」;issue 延後到「確定有保留問題」才建立;無保留問題或無可審查變更則不建 issue、PR 也完全不留言(靜默通過);有問題時最後在 PR 回貼一則 issue 連結並補掛標籤,形成雙向關聯。action.yml/src各模組文件、重建readme.md,新增.gitea/workflows/ci.yaml(多工具 code review 驗證)並啟用建問題模式。影響範圍
src/index.jsmain()依模式分流:留言去向、跳過 resolveOldComments、issue 延後建立、severe/others 導向 issue、有問題才在 PR 回貼連結src/lib/gitea.js新增addLabelsToIssuesrc/lib/templates.js新增issueLinkCommentsrc/lib/review.js新增postSevereToIssue,移除createIssueWithFindings、sortFindingsForIssuesrc/lib/gitrepo.js補抓淺層 checkout 的 base 歷史readme.md、action.yml、.gitea/workflows/ci.yaml、.gitea/workflows/readme.md風險與注意事項
readme.md尚未反映「建問題模式導向 issue」的最新行為與新/移除的函式,建議後續以 doc-funcs 重建文件。2026/07/17 18:49:58,未刷新。🤖 AI Code Review|審查工具
codexcodex-cli 0.144.6gpt-5.5321a717f91303bd4b865eacb0d11546ef9e79e11📋 變更摘要(送審 git diff)
action.ymlreadme.mdsrc/index.jssrc/lib/agents.jssrc/lib/context.jssrc/lib/gitea.jssrc/lib/gitrepo.jssrc/lib/review.jssrc/lib/roles.jssrc/lib/templates.js⚔️ 攻擊方登場
🛡️ 防守方登場
🟠 警告|🧰 Leo
位置:
src/index.js第 119–149 行問題描述
流程步驟編號現在變成維護負擔:步驟 2 被描述為「延後執行」,實際程式順序又在步驟 8 後、步驟 9 前才跑;同一批編號還同步出現在
readme.md、templates.js、review.js、gitea.js、agents.js的註解與 log。這類人工同步的流程編號很容易在下一次調整時再次漂移,讀者會拿到一份看似精準、其實要逐檔對照才敢相信的文件。修改建議
把對外文件保留高層流程即可,程式內 log 建議改用穩定語意名稱,例如
tool-detect、diff-summary、resolve-old-comments、publish-findings,不要依賴會重排的數字。若一定要顯示步驟,集中定義在一個 workflow metadata 常數,由 README 產生或至少讓 templates/log 共用同一份來源。🟠 警告|⚡ Rogue
位置:
src/lib/gitrepo.js第 133–134 行問題描述
這裡把
--unshallow origin放在第一個補抓策略。淺層 checkout 一旦首次merge-base失敗,就可能直接下載整個遠端歷史與多個 ref;大型 repo 會把原本幾秒的 diff 準備拖成數分鐘,還吃掉大量網路與磁碟。這不是微優化,是 CI 熱路徑上的整包歷史下載。修改建議
先用有界的 refspec deepen 補 base 與 HEAD,只有都失敗時才把
--unshallow當最後手段。這樣大多數 PR 只補需要的歷史深度,不會一開始就吞完整 repo。建議寫法
🟠 警告|🔮 Mage
位置:
src/lib/gitrepo.js第 143–143 行問題描述
淺層 checkout 且
--unshallow失敗時,deepen HEAD策略實際執行的是git fetch --deepen=1000 origin HEAD。這裡的origin HEAD是遠端預設分支,不一定是目前 PR 的 head 分支或目前 detached HEAD 的祖先。最小重現情境:PR 來源分支是
feature/x,runner checkout 到該 PR head 的 shallow commit;遠端預設分支是develop;--unshallow因伺服器限制失敗。此時 deepen 的是develop,不是feature/x,merge-base origin/<baseRef> HEAD仍可能失敗,導致整個審查流程中止。修改建議
不要用遠端預設
HEAD代表 PR head。把 PR head ref 或 head SHA 傳入resolveMergeBase,針對實際 PR head 補抓歷史;若只能取得 SHA,至少在錯誤訊息中明確指出無法 deepen PR head,而不是執行不相關的origin HEAD。🔵 建議|🎼 Bard
位置:
action.yml第 3–3 行問題描述
手寫的「更新時間」仍停在 2026/07/17,但本次變更明顯新增了
push-token等內容;這種時間戳像失準的節拍器,會讓讀者懷疑文件是否可信。修改建議
移除手動維護的更新時間,或改由發布/產檔流程自動產生,避免每次修改都要靠人肉同步。
🔵 建議|🧰 Leo
位置:
src/lib/review.js第 13–72 行問題描述
redactSecrets()與agentFailureDetail()是低階日誌診斷/遮罩邏輯,現在放在review.js這個負責 diff 整理與審查決策的模組頂端。這會讓review.js的職責繼續膨脹:未來若其他模組也要安全輸出 CLI 錯誤,只能複製這段或反向依賴 review 模組,邊界會越來越不清楚。修改建議
把這兩個函式搬到專門的工具模組,例如
src/lib/diagnostics.js或src/lib/log-redaction.js,並由review.js引入。這樣遮罩規則可集中測試與重用,review.js也能維持在「審查流程資料處理」的邊界內。🔵 建議|🎼 Bard
位置:
src/lib/review.js第 41–45 行問題描述
這段註解的旋律前後走調:摘要先說「原始輸出預設隱藏」,下一段卻說失敗時「預設附上 stderr 與 stdout」。讀者還沒進函式本體,文件本身就已經互相拉扯。
修改建議
請讓摘要與實作同拍,直接說明會輸出經遮罩與限長的診斷片段;若真的要隱藏原始輸出,也應同步改實作。
建議寫法
🔵 建議|🎼 Bard
位置:
src/lib/templates.js第 334–338 行問題描述
issueFindingComment的文件只唱「嚴重 finding」,但新版流程也讓警告與建議逐條發到 issue。函式名稱是通用的,註解卻把用途寫窄,後續讀者會誤以為它只服務嚴重問題。修改建議
把註解改成涵蓋所有 finding 等級,讓文件與函式名稱、呼叫情境保持一致。
建議寫法
🧩 code-review-resolve 處理進度
本議題為 AI Code Review 建問題模式的追蹤議題。以
--issue all併同.gitea/ai-review/findings/逐條處理後結果如下(對照目前程式碼與exclusions.json):src/index.js第 119–149 行src/lib/gitrepo.js第 133–134 行src/lib/gitrepo.js第 143–143 行action.yml第 3–3 行src/lib/review.js第 13–72 行src/lib/review.js第 41–45 行src/lib/templates.js第 334–338 行小計:✅ 已解決 2 條、🚫 誤報(已列入 exclusions)2 條、⏭️ 待人工處理 3 條。
resolveMergeBase補抓策略調整、deepen PR HEAD改用 head SHA、留言閉包改名、push-tokeninput 移除等)。.gitea/ai-review/exclusions.json既有裁決等價,不重複新增排除條目。處理完成,依 code-review-resolve 流程關閉本議題。