Trace: batch staged blob reads during Bash commit checkpoints

Abierto
  • ¿Algo no está bien?
#3,749 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
bash, git, go
Área
devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
582
Forks
61
Merge medio
12 h 47 min
PR fusionados (30 d)
137

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de chainloop-dev/chainloop

Todos los issues de chainloop-dev/chainloop

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.