Trace: batch staged blob reads during Bash commit checkpoints

Aperta
  • Qualcosa non va?
#3,749 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
bash, git, go
Ambito
devtools

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

chainloop component/CLI performance trace-provider

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.

Lingua principale
Go
Stelle
582
Fork
61
Merge medio
12h 47m
PR unite (30g)
137

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di chainloop-dev/chainloop

Tutte le issue di chainloop-dev/chainloop

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.