Trace: batch staged blob reads during Bash commit checkpoints

Aberta
  • Algo errado?
#3,749 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
25/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Estagnada
Stack de tecnologia
bash, git, go
Domínio
devtools

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Go
Estrelas
582
Forks
61
Merge médio
12h 47min
PRs com merge (30d)
137

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de chainloop-dev/chainloop

Todas as issues de chainloop-dev/chainloop

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.