【架构优化】从 DeliveryRepo.applyMRDeliveryStates 中拆出工作项自记 MR 状态覆盖 overlayIssueMRState

未關閉
#480 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

@fx-kurumi 已經在處理了。

開始於 2026年11月13日。

  • #481 來自 @fx-kurumi —— 未關閉

評估

難度
2/5
預估耗時
1-3 小時
新手友好度
25/100
Issue 類型
重構
描述清晰度
描述清楚
活躍度
停滯
技術堆疊
go
領域
backend

研究方向

Read internal/repo/delivery.go, especially DeliveryRepo.applyMRDeliveryStates, and inspect the existing repo tests such as mr_delivery_memory_test.go. A linked pull request (#481) is already open for this work, so it is not a good first-contribution task to pick up.

由索引模型根據 Issue 內容生成。

描述

现状问题

internal/repo/delivery.go 中 DeliveryRepo.applyMRDeliveryStates 约 125 行,在「遍历 issue 的每个 MR」循环内又嵌套了一段循环:逐个比对 issue.DeliveryMRList(),用工作项自己记录的 MR 状态去补齐/升级查询到的状态(unknown 时回退、否则走 EffectiveAnalyticsMRState)。这段逻辑:

  • 嵌套 4 层(for → for → if → if/else),读起来要同时记住外层 best/seen 等变量;
  • 每个 MR 引用都重新调用一次 DeliveryMRList()(每次都会复制切片);
  • 没有单独的测试,只能通过整条分析链路间接覆盖。

重构方案

  • 抽出包级纯函数 overlayIssueMRState(state, url string, own []domain.DeliveryMR) string,原样搬移这段判断;
  • applyMRDeliveryStates 在单个 item 的循环开头取一次 own := issues[id].DeliveryMRList(),内层改为一行调用。

影响范围

仅 internal/repo/delivery.go(以及新增测试文件),不改导出接口、不改行为。

验证方式

  • 新增 overlayIssueMRState 单元测试,覆盖:无匹配、unknown/空状态回退、own 状态为空不覆盖、integrated + merged 升级、URL 归一化匹配;
  • 现有 mr_delivery_memory_test.go 等 repo 测试通过;gofmt、go vet ./internal/repo/、go test ./internal/repo/ 通过。
主要語言
Go
星號
141
分支
28
平均合併
1 天 15 小時
30 天內合併 PR
113

環境準備

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

Tencent/LoopForge 的其他 Issue

查看 Tencent/LoopForge 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。