ci(nix): print the get-sources duration on every attempt, not just failures - #436
Conversation
…ilures The measurement added in #429 was there to compare the sources path against record's, and the first run carrying it printed only record's: the grep sat inside a failure branch, so the successful side -- the interesting half -- went into a scratch file and stayed there. The durations had to be reconstructed from log timestamps instead, which is exactly the guessing the instrumentation was meant to replace. Move both greps ahead of the branching, so a success reports its duration too. On the record side that matters more than on sources: a record that works is the one measurement this path has never produced. Also fold the sources capture into 2>&1 like record and export. The probe at the top of the step established that this host's xvfb-run merges stderr into stdout, so the separate .err file could never hold anything, and every reader that went looking for output in it found an empty file and drew the wrong conclusion. What the reconstruction already shows, for whoever reads this next: enumeration here is bimodal, not slow. Successes land at 377-491ms including Electron start; failures do not return at all and are cut by whichever bound applies -- 20s in the sources runner, 30s in the shared handler. There is no middle, so no threshold to tune, which is worth knowing before anyone tries. Co-Authored-By: Claude <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 4 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughThe Nix build workflow now captures combined output for ChangesNix build diagnostic reporting
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This change makes CI source-fetch durations visible on successful and failed attempts without changing product code or build behavior; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What this does
The
get-sourcesduration added in #429 exists to compare thesourcespath againstrecord's. The first run carrying it printed onlyrecord's — the grep sat inside a failure branch, so the successful side, which is the interesting half, went into a scratch file and stayed there. The durations had to be reconstructed from log timestamps, which is the guessing the instrumentation was meant to replace.Both greps move ahead of the branching. On the
recordside that matters more than onsources: arecordthat works is the one measurement this path has never produced.The
sourcescapture also folds into2>&1, likerecordandexportalready do. The probe at the top of the step established that this host'sxvfb-runmerges stderr into stdout, so the separate.errfile could never hold anything.What the reconstruction already shows
Worth recording, because it settles a question left open in #429 — whether the 30s bound in the shared handler is too tight for a slow runner.
It is not. Enumeration on this host is bimodal, not slow:
Successes land under half a second including Electron start. Failures do not return at all and are cut by whichever bound applies — 20s in the sources runner, 30s in the shared handler. There is no middle, so there is no threshold to tune, and raising the bound would buy nothing.
The asymmetry that motivated the measurement holds and got stronger:
recordhas taken the non-returning path 6 times out of 6 across two runs, against roughly 5 in 10 forsources. At a 40% per-attempt rate, six in a row is under 0.5%, so something about therecordpath looks specific rather than unlucky. This PR does not attempt that; it makes the next run able to say so with a number.Verified
Workflow YAML parses; all four embedded
runblocks passbash -n. No remaining reference to the removed.errfile. No code changes, so no test or typecheck impact.Not verified: the durations this is meant to print. That takes a run on
main.🤖 Generated with Claude Code
Summary by CodeRabbit