feat(ai-code-review): 建問題模式導向 issue,並整併流程調整、文件與 CI #25
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#25
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.55ac73f290e31cc6bf36fff047829ef251a51468c📋 變更摘要(送審 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⚔️ 攻擊方登場
🛡️ 防守方登場
🔴 嚴重|🔮 Mage
位置:
src/index.js第 398–415 行問題描述
建問題模式在「有嚴重問題、但 exclusions.json 沒有變更」時不會產生任何
[failure]結果 commit,最後仍回傳 0。最小重現:create-issue=true、攻擊/防守後kept含 1 條severity === '嚴重'、excluded為空,所以exclusionsChanged === false。流程會建立 issue、嘗試掛 dependency,接著進入建問題模式且 exclusions.json 無變更,略過 commit/push,最後return 0。此時既沒有本輪 exit 1,也沒有下一輪可讀取的 failure commit;若 issue dependency 未啟用或設定失敗又被 catch 降級,PR 檢查會顯示通過。修改建議
不要讓嚴重問題的失敗狀態只依賴可選的 exclusions commit。建問題模式只要
severe.length > 0,應至少保證一個可被下一輪讀到的 failure marker commit,或在無法產生 marker 時直接return 1。若設計上 dependency 是阻擋合併的來源,則 dependency 建立失敗時不能降級為通過。🟠 警告|🔮 Mage
位置:
src/index.js第 409–415 行問題描述
本輪審查一律
return 0的前提是「結果 commit 一定會觸發下一輪」。但action.yml只建議使用 PAT,沒有驗證ctx.token真的能觸發 CI。最小重現:一般模式發現嚴重問題,result === 'failure',使用者仍傳入自動 token;程式成功 push failure commit,但該 push 不觸發 workflow,於是沒有下一輪步驟 1 回報 exit 1,本輪又固定回傳 0,檢查結果會錯誤地通過。修改建議
失敗狀態不能建立在未驗證的 token 行為上。建議在
severe.length > 0時,若無法確認已用可觸發 CI 的 PAT 產生下一輪檢查,就維持本輪return 1;或新增明確 input(例如deferred-failure=true)並在未啟用時直接失敗。🔵 建議|🧰 Leo
位置:
src/index.js第 194–232 行問題描述
queueOrPostComment()會依閉包狀態回傳Comment或null,同時還會修改issueBuffer/currentRunCommentIds。這種「同一個方法但回傳型別和副作用隨模式變」的介面,現在呼叫端剛好不使用回傳值所以看似無害;未來有人若要在留言後讀created.id或做錯誤補償,很容易踩到建問題模式尚未建立 issue 時回傳null的隱藏分支。修改建議
讓介面語意更窄:若呼叫端不需要留言物件,就讓函式固定回傳
Promise<void>;若需要留言結果,則拆成postPrCommentAndTrack()與bufferOrPostIssueComment()。避免一個 helper 同時承載兩種模式與兩種回傳契約。🧩 code-review-resolve 處理進度
本議題為 AI Code Review 建問題模式的追蹤議題。以
--issue all併同.gitea/ai-review/findings/逐條處理後結果如下(對照目前程式碼與exclusions.json):src/index.js第 398–415 行[failure]commit」為刻意的兩階段失敗設計,exclusions.json已有多筆等價 Mage 嚴重裁決。src/index.js第 409–415 行src/index.js第 194–232 行queueOrPostComment(前身 postComment)依模式回傳型別/副作用不同、main() 閉包應抽出 publisher,屬既有可維護性設計取捨,已列入 exclusions。小計:✅ 已解決 0 條、🚫 誤報(已列入 exclusions)3 條、⏭️ 待人工處理 0 條。
處理完成,依 code-review-resolve 流程關閉本議題。