Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Turn committed evidence receipts into executable regression fences and move bulky evidence out of the repository

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

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
ci-cd, release, testing, tooling

Direzione di ricerca

Start by inventorying tests/enry-performance/results/final/ and the compatibility_v030, _v050, _v060, _next, and _v100 directories, then inspect the existing CI harnesses. Classify each committed result family as a fence, archive, delete, or replacement. Done means a rolling compatibility harness runs in CI, large evidence is removed from tests/, repository size is recorded, and README/docs figures come from harness output.

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

Descrizione

enhancement follow-up

Why

tests/ holds ~182 MB of committed results: JSON receipts, evidence.tar.gz bundles and audit exports. Much of it is inert: no executable test re-runs the claim against the current binary.

  • tests/enry-performance/results/final/ alone is ~110 MB: a 66 MB evidence.tar.gz and a 48 MB audit.json.
  • There are per-version compatibility harnesses: compatibility_v030, _v050, _v060, _next and _v100.
  • Performance, stress, profiling and release results are all committed as JSON.

A receipt shows that something was true once. A regression fence shows that it's still true. Only fences protect 1.0 and later releases. The bulk also slows clones and makes the repository harder to read before it goes public.

Proposal

  • For each committed receipt family, decide whether it's still a claim we make.
    • If so, replace it with a re-runnable harness that produces a fresh result and compares it with a reviewed reference, with a tolerance where the measure is noisy.
    • If not, archive it.
  • Consolidate the per-version compatibility directories into one rolling compatibility harness that runs against the last N released binaries, checksum-pinned and downloaded or cached, with the reviewed-exception mechanism kept.
  • Move large evidence (tarballs, audit exports, raw timing dumps) to release assets or a separate evidence repository. Keep only manifests and hashes in-tree. Do this before the repository becomes public, while a history rewrite is still cheap.
  • Generate the public numbers (README and docs benchmark tables) from harness output, not by hand.

Acceptance

  • Inventory of every committed result family, each marked fence / archive / delete.
  • Rolling compatibility harness in CI, replacing the per-version directories.
  • tests/ holds no large binary evidence, and repository size after cleanup is recorded.
  • README/docs performance and conformance figures regenerated from harness output.

Part of the 1.0 quality program: #83. Epic: #81.

Lingua principale
Go
Stelle
0
Fork
0
Merge medio
5h 8m
PR unite (30g)
54

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 war-and-code/dircue

Tutte le issue di war-and-code/dircue

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.