Trace: batch staged blob reads during Bash commit checkpoints
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
The issue says this work was implemented in #3631 by commit 77d2fe0e, so start by reviewing that commit and the linked Bash checkpoint code and tests. The remaining task is to record comparable before and after timings for the 301-file scenario described in #3631; the issue gives no timing procedure or test file to start from.
由索引模型根據 Issue 內容生成。
描述
Problem
In #3631, checkpointActiveShellAttribution calls ExecClient.IndexFile for each changed staged path. Every call scans the full index with git ls-files --stage and starts git cat-file --batch for one blob, although afterIndex[relPath] already contains its hash.
In @jiparis's review, a Bash call that staged 301 files in a 3.3k-file checkout took 10.6 seconds at commit-msg; the per-file index/blob reads account for about 5 seconds. The reviewer explicitly accepted this as a follow-up, not a blocker for #3631.
Scope
Read only the changed staged blobs by their already captured hashes in one git cat-file --batch call. Preserve the effective-index snapshot (including split, sparse, and temporary indexes), the GoGit fallback, exact binary content, and existing same-call attribution behavior.
Acceptance criteria
- The checkpoint takes one index snapshot and one batch blob read, without a full-index scan or Git process per changed file.
- Regression tests cover multiple staged files, binary content, and hashes captured before a later index change; existing Bash commit lifecycle tests pass.
- Record comparable before/after timing for the many-file scenario in #3631, without a timing-sensitive test assertion.
Implemented in #3631 by commit 77d2fe0e; the many-file timing remains to be recorded.
- 主要語言
- Go
- 星號
- 582
- 分支
- 61
- 平均合併
- 12 小時 47 分鐘
- 30 天內合併 PR
- 137
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
chainloop-dev/chainloop 的其他 Issue
-
feature-parity trace-provider
難度 2/5 1-3 小時 新手友好度 70/100
chainloop-dev/chainloop#3802 ·
維護者通常 1 天內回覆
-
bug trace-provider
難度 4/5 3-5 天 新手友好度 48/100
chainloop-dev/chainloop#3803 ·
維護者通常 1 天內回覆
-
feat(trace): support GitHub Copilot (CLI and VS Code) in Chainloop Trace可能已有人在做 @migmartri 今天認領。 未關閉Feature spec trace-provider
chainloop-dev/chainloop#3800 · 1 則留言 · 已指派 1 人 ·
維護者通常 1 天內回覆
-
Allow enabling policy enforcement at the workflow contract level可能已有人在做 @migmartri 於 10 天前認領。 未關閉component/backend new-policy spec
chainloop-dev/chainloop#3762 · 1 則留言 · 已指派 1 人 ·
維護者通常 1 天內回覆
-
chainloop component/CLI performance trace-provider
難度 4/5 3-5 天 新手友好度 62/100
chainloop-dev/chainloop#3756 ·
維護者通常 1 天內回覆
查看 chainloop-dev/chainloop 的全部 Issue
相似的 Issue
-
GitHub webhook is not subscribed to release events, so `event: release` never triggers可能已有人在做 @qsun 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 78/100
woodpecker-ci/woodpecker#7542 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 74/100
zilliztech/milvus-backup#1386 ·
維護者通常 1 天內回覆
-
Pipelined flush no longer observes kill signals after #2042: flush backoffer is built with nil vars未關閉
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
model:sonnet runtime:claude security size:S
難度 2/5 1-3 小時 新手友好度 78/100
FootprintAI/Containarium#3624 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 86/100
維護者通常 1 天內回覆