feat: 導入 AI 程式碼審查 action 並修正進入點與參數接線 #1
+6
-1
@@ -1,4 +1,5 @@
|
||||
import path from 'path';
|
||||
import { pathToFileURL } from 'url';
|
||||
|
admin marked this conversation as resolved
Outdated
|
||||
import { GITEA_REPOSITORY, PR_NUMBER, PR_HEAD_BRANCH, PR_BASE_BRANCH, getLLMConfig, FINDINGS_PATH, EXCLUSIONS_PATH } from './config.js';
|
||||
import { loadRoles, getRoleIntro } from './roles.js';
|
||||
import { getPRDiff, postComment, getCommitMessageBySha, getBotReviewOutcome, shouldSkipBotCommit } from './gitea.js';
|
||||
@@ -52,7 +53,7 @@ const WORKSPACE = process.env.GITHUB_WORKSPACE || '/workspace';
|
||||
* 降級處理:Step4 對話收斂、Step5 角色介紹 comment 與個別角色分析、Step6 clone repo、
|
||||
* Step8 Review 發布等非致命步驟失敗時,僅 `warn` 後繼續執行。
|
||||
|
admin marked this conversation as resolved
admin
commented
嚴重等級:🟡 警告 **嚴重等級**:🟡 警告
**審查員**:Leo
**問題**:`main()` 已經變成整條 pipeline 的超級入口,11 個 step、exit 判斷、資料收集、排序/過濾與發布全部擠在同一個函式裡。未來只要某一步的前置條件改了,維護者就得在這個巨型函式裡追完整條狀態流,認知負擔很高。
**建議**:把每個 step 拆成獨立函式並回傳明確的 context,讓 `main()` 只負責流程編排與最終 exit 決策;這樣之後新增步驟或調整順序時,不會把整條 pipeline 綁死在同一個函式裡。
|
||||
*/
|
||||
async function main() {
|
||||
export async function main() {
|
||||
section('AI Code Review Pipeline');
|
||||
|
||||
// Step1 啟動
|
||||
@@ -236,7 +237,11 @@ async function main() {
|
||||
section('Pipeline 結束');
|
||||
}
|
||||
|
||||
// 僅在作為 CLI 進入點(node src/main.js)執行時自動啟動 pipeline;
|
||||
// 被 import(例如單元測試)時不自動執行,方便注入 mock 測試各分支。
|
||||
if (process.argv[1] && import.meta.url === pathToFileURL(process.argv[1]).href) {
|
||||
main().catch(e => {
|
||||
error(`Runner failed: ${e.message}`);
|
||||
process.exit(1);
|
||||
});
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user
嚴重等級:🟡 警告
審查員:Bard
問題:這一行 import 把大量設定常數擠成長長一串,讀起來像沒有換氣的樂句,與後續同檔案多個長 import 一起讓檔案開頭難以掃描。
建議:將多項具名 import 改成多行排列,並依來源模組分組維持一致節奏,例如每個匯入項目獨立一行。