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

Mainframe Ground Truth: stop paying the 3-4 min warm-up per part; ~11 min PR check, now the slowest

Aperta
  • Qualcosa non va?
#5,543 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, python, yaml
Ambito
ci-cd, performance, testing

Direzione di ricerca

Start with .github/workflows/mainframe-ground-truth.yml, then inspect test_ci_critical_path_split and the parts-pattern test referenced by #5522. Measure each ledger-gate and pytest-split step in the cited run IDs, and choose among the three proposed warm-up layouts before editing the workflow. Done means ground-truth remains the required aggregate check, ledger verdicts and test counts match main, and a PR records wall time and runner-minutes against the ≤ 7.5 minute target.

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

Descrizione

ci-cd github-actions performance scope:infra

Measured (2026-10-18, 5 successful PR runs): mainframe-ground-truth.yml is now the slowest PR check, about 11 min (parts 1/2 and 2/2 both ~11.0 min on the sampled head). Since #5530 sharded CICS Crucible (24.8 → ~8.2 min), every PR waits on this check. The next slowest are graph-accuracy-audit (7.6 min, #5501) and muninn (7.5 min, #5499).

Where the time goes, per part (step times from runs 39171967813, 39170181810, 39170005710, 39168823386, 39168781317):

step part 1/2 part 2/2
Install GitGalaxy 0.4 min 0.3-0.5 min
Gate against the ground-truth ledger 3.1-4.1 min 2.4-4.2 min
Full-corpus differential and answer-key tests (pytest-split share) 4.7-6.4 min 3.8-6.3 min

Part 1 is the long one every time (4.1 + 6.4 min). The ledger gate runs on both parts (#5133), so each part's corpus scans are warm before the timed tests. That 3-4 min is paid once per part, so adding parts adds it again: 4 parts as they are today come to about 4 + 3 + setup ≈ 8 min, not 11/2.

Proposed (the worker measures and picks, then reports)
  • Stop paying the warm-up per part. Options, cheapest first:
    • (a) scan the pinned corpora once in a warm job and pass the scan outputs to the parts as an artifact. The parts then run pytest against warm results and skip the full ledger gate; only one job runs the gate, its summary and history.
    • (b) let each part warm only the corpora its pytest share touches, not the whole set.
    • (c) more pytest-split groups (3-4) with the current per-part warm-up, if (a) and (b) don't fit. This is the fallback with the smallest gain.
  • Rebalance part 1 versus part 2 (part 1 is the long pole every run; refresh .test_durations if it's stale).
  • Keep ground-truth as the one required check name (the aggregate job stays; the ruleset names it).

Rule: the same ledger gate, the same tests and the same per-test time ratchet. No test moves out of the PR check. test_ci_critical_path_split and the parts-pattern test (#5522) follow the new layout.

Acceptance: PR wall time of the check before and after (target ≤ 7.5 min, level with the next slowest check) and total runner-minutes, in the PR body. The first CI run shows the same ledger verdict and test counts as main.

Value: about 3.5 min less per PR push on the critical path. At 60-80 runs/day over the 2-week CICS push, that's about 50-65 hours less PR waiting.

Owner decisions

Owner OK (2026-10-18): the mainframe-ground-truth.yml workflow edit is approved (allow_workflows), queued on nyx.

🤖 Generated with Claude Code

Lingua principale
Python
Stelle
57
Fork
11
Merge medio
1h 43m
PR unite (30g)
985

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 squid-protocol/gitgalaxy

Tutte le issue di squid-protocol/gitgalaxy

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.