feat(ai-code-review): 建問題模式導向 issue,並整併流程調整、文件與 CI #12
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#12
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.671b93a885a068701fc7a99cd624d9cab8bba3a3a📋 變更摘要(送審 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⚔️ 攻擊方登場
🛡️ 防守方登場
🔴 嚴重|⚡ Rogue
位置:
src/lib/gitrepo.js第 133–135 行問題描述
淺層 checkout 找不到 merge-base 時,第一個補救策略就執行
git fetch --unshallow origin,會下載整個儲存庫歷史;大型或長壽 repo 可能多抓數 GB 資料、耗費數分鐘與大量磁碟/網路 I/O,即使只需再補少量 commit 就能找到共同祖先。後面的 bounded--deepen=1000幾乎失去節流意義。修改建議
把有限深度補抓排在前面,每次補抓後立即重試 merge-base;只有多次 bounded deepen 仍失敗時,才把
--unshallow當最後手段。建議寫法
🟠 警告|🧰 Leo
位置:
readme.md第 59–130 行問題描述
功能索引把分支名稱與原始碼行號硬編碼在數十個連結中;本次僅因程式碼增行,就必須人工把大量
#L...全面更新,已直接顯示這份文件存在高同步成本。之後任一檔案前段增刪程式碼,都會讓這些連結再次漂移,而且指向會持續變動的develop分支,使舊版 README 與實際連結內容無法穩定對應。修改建議
不要手動維護原始碼行號。若只需導覽,連到檔案並由右欄既有章節錨點提供函式級定位;若必須精確指向定義,應由 AST/文件產生工具在 CI 自動建立索引,並連到固定 commit SHA 或版本 tag。至少增加連結檢查,避免半年後整張功能表悄悄失準。
建議寫法
🟠 警告|🎼 Bard
位置:
src/index.js第 122–145 行問題描述
流程號碼已失去「執行順序」的直覺:文件先介紹步驟 2,實際程式卻依序執行 3~8、再折返執行 2。讀者必須在註解、流程圖與實作之間來回對照,後續每次插入流程還得同步修改散落各檔案的大量步驟編號,維護旋律相當容易走調。
修改建議
讓編號維持實際執行順序,將「清理舊留言」重新編為步驟 9,後續發布與收尾依序遞延;若數字代表概念階段而非時序,則改用具名階段(如「準備」、「分析」、「清理」、「發布」),不要再稱為固定 10 步驟。
🔵 建議|🧰 Leo
位置:
src/lib/review.js第 13–82 行問題描述
agentFailureDetail()同時負責解析程序失敗、決定 debug 政策、讀取全域環境變數、截斷輸出及遮罩機密。尤其直接讀取process.env.ACTIONS_STEP_DEBUG形成隱藏相依,測試不同輸出政策時必須修改程序全域狀態;日後若其他呼叫端需要不同診斷層級,也只能繼續往這個函式堆條件。修改建議
把診斷政策改成明確參數,並將「錯誤中繼資料整理」與「輸出片段清理」拆成小函式;在
main或 context 載入階段解析環境設定後注入。這能讓各種 exit code、signal、空輸出與 verbose 模式以純輸入輸出直接測試。建議寫法
🧩 code-review-resolve 處理進度
本議題為 AI Code Review 建問題模式的追蹤議題。以
--issue all併同.gitea/ai-review/findings/逐條處理後結果如下(對照目前程式碼與exclusions.json):src/lib/gitrepo.js第 133–135 行readme.md第 59–130 行src/index.js第 122–145 行src/lib/review.js第 13–82 行小計:✅ 已解決 1 條、🚫 誤報(已列入 exclusions)1 條、⏭️ 待人工處理 2 條。
resolveMergeBase補抓策略調整、deepen PR HEAD改用 head SHA、留言閉包改名、push-tokeninput 移除等)。.gitea/ai-review/exclusions.json既有裁決等價,不重複新增排除條目。處理完成,依 code-review-resolve 流程關閉本議題。