【架构优化】拆分 runner.collectTaskOutputs 的输出文件读取、补丁目录推导与补丁采集

オープン
#431 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@fx-kurumi がすでに取り組んでいます。

2026年11月13日 から。

  • #432 @fx-kurumi による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
22/100
issue の種類
リファクタリング
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
git, go
領域
devtools

調査の方向性

Work is confined to internal/runner/outputs.go, where collectTaskOutputs mixes file reading, patch-directory derivation and patch collection. The payload names no entry point beyond that function. Done means three helpers are extracted with unchanged behaviour, the existing TestCollectTaskOutputsReportsOnlyRegularFilesInsideWorkspace still passes, and new tests cover the extracted pieces. However, a linked pull request (#432) is already open, so the work is likely claimed.

索引モデルが issue の本文から書いたものです。

説明

现状问题

internal/runner/outputs.go 的 collectTaskOutputs 约 50 行,在一个函数里串行做了三件互不相关的事:

  1. 逐个读取 OutputFiles(路径安全校验、Lstat 只认普通文件、超过 maxArtifactUploadBytes 记入 TooLarge、读入 Files);
  2. 推导需要采集补丁清单的仓库目录(无仓库时为工作区根 "",否则为各仓库的 safeRunnerRepoDir(WorkspaceDir)),并逐个调用 gitwork.PatchInventory 填 Patches;
  3. 检测前端工作区事实 Facts。

其中「仓库目录推导」是纯逻辑却埋在 I/O 循环里,无法单独测试;现有测试也只覆盖了第 1 步。

重构方案

仅在 internal/runner/outputs.go 内拆函数,不改逻辑:

  • readOutputFiles(workspace, rels) (files map[string]string, tooLarge []string):原第 1 段循环原样搬入;
  • patchInventoryDirs(inv) []string:原目录推导原样搬入;
  • collectPatchInventories(workspace, dirs) map[string]string:原补丁采集循环原样搬入;
  • collectTaskOutputs 只负责编排:恢复缺失输出 → 读文件 → 采补丁 → 采事实。

nil map / nil slice 的语义保持不变(没有文件时 Files/Patches 仍为 nil,JSON omitempty 输出不变)。

影响范围

仅 internal/runner/outputs.go(及新增测试文件),collectTaskOutputs 签名与三个调用方(daemon.go)不变,对外接口与行为不变。

验证方式

  • 新增测试覆盖 patchInventoryDirs(无仓库 / 多仓库)、collectPatchInventories(真实 git 仓库有改动 / 无改动 / 非仓库目录)与 readOutputFiles 的 nil 语义;
  • 原有 TestCollectTaskOutputsReportsOnlyRegularFilesInsideWorkspace 不改动且通过;
  • gofmt、go vet ./internal/runner/、go test ./internal/runner/。
主要言語
Go
スター
141
フォーク
28
平均マージ
1日 15時間
マージ済み PR(30日)
113

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Tencent/LoopForge のほかの issue

Tencent/LoopForge の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。