mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-31 19:16:29 +00:00
8fd2efe223
The gantt drew one bar per job and threw away the step timings it was already collecting, so "which part of this job is slow" meant opening the run in the GitHub UI and reading steps by hand. Job bars are now segmented by step, with a divider and a hover tooltip (name, duration, category) per segment, and clicking a job expands it into per-step rows on the same time axis. There's an expand/collapse-all control. No new data is fetched — `_normalize_job` already recorded every step's start/end; this is rendering only, so the report job costs the same. Adds a "Setup vs Work" section that buckets every step into setup / work / teardown and reports the split as a stacked bar plus a table of the individual overhead steps that cost the most summed across jobs. On the run this was built against: 62% of accounted step time is setup+teardown, and checkout alone (1675s across 42 jobs) exceeds all real work combined — which is the kind of thing the report should say out loud rather than leave to inference. Classification is deliberately conservative: unrecognized step names count as work, so the figure under-reports overhead rather than inflating it. Also strips the pinned SHA from action refs when displaying step names — "Run actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd" renders as "Run actions/checkout". Display only; the raw name stays the key for baseline comparison, since two different pins are two different steps. Applied to the pre-existing step-details and regressions tables too, which had the same readability problem. |
||
|---|---|---|
| .. | ||
| assemble_review_comment.py | ||
| classify_changes.py | ||
| e2e_screenshot_status.py | ||
| emit_review_status.py | ||
| live_comment.py | ||
| lockfile_diff.py | ||
| publish_e2e_evidence.py | ||
| resource_profile.py | ||
| timings_report.py | ||