4.2 KiB
REVIEW-dash — Adversary verdicts for phase dash (per-recipe run history fix)
SSOT: /srv/cc-ci/cc-ci-plan/plan-phase-dash-recipe-history.md Gates: M1 (fix implemented + locally verified), M2 (deployed + verified live).
Pre-claim independent ground truth (Adversary, @2026-06-17T16:20Z, cold)
Gathered directly from the host (ssh cc-ci), BEFORE any Builder claim — this is my own
baseline to verify the fix against, not the Builder's narrative.
Run artifacts on host /var/lib/cc-ci-runs:
- 432 run dirs total; 308 have a parseable
results.json; 124 dirs have NO parseableresults.json(in-flight / failed-early — contain onlyjunit/,screenshot.png,abra/). The fix MUST skip these 124 gracefully (no 500). results.jsonschema 2 keys:customization, finished, flags, level, lint, pr, recipe, ref, results, run_id, rungs, schema, screenshot, skips, stages, summary_card, version. Fields the history needs ARE present:recipe,version,level,ref,finished(epoch float timestamp),run_id. Status is derivable fromresults/rungs(per-stage pass/fail).
Per-recipe run counts (from parseable results.json):
33 plausible 24 ghost 9 mailu 6 cryptpad
33 custom-html 24 custom-html-tiny 8 lasuite-drive 3 drone
28 immich 15 mattermost-lts 8 lasuite-docs 3 custom-html-rst-bad
25 discourse 12 uptime-kuma 8 gitea
24 (ghost) 12 mumble 8 bluesky-pds
11 matrix-synapse 7 custom-html-bkp-bad
10 lasuite-meet 6 keycloak
9 n8n 6 hedgedoc
bluesky-pds(named M2 target) → 8 runs.plausible/custom-html→ 33 (exceed a 30 cap → good cap test). A ~30 display cap should show 8 for bluesky-pds, 30 for plausible/custom-html.
bluesky-pds runs — newest-first BY finished timestamp (the correct order):
run_id ref level finished
753 dcf933813df9 5 1781663348
556 f7b6c8dfb81c 5 1781301301
435 f7b6c8dfb81c 5 1781192858
427 f7b6c8dfb81c 5 1781178768
423 f7b6c8dfb81c 0 1781178063
ab-bluesky-pds-oldmain b2d86efba3f1 0 1781126338
m2rr-bluesky-pds b2d86efba3f1 0 1781123524
m2r-bluesky-pds b2d86efba3f1 0 1781121610
ADVERSARIAL TRAP TO CHECK: run ids are MIXED numeric (753,556,…) AND named
(m2rr-bluesky-pds, ab-bluesky-pds-oldmain). Sorting by int(run_id) would crash or misorder
the named runs; sorting lexically would put 9... after 7... wrongly and scatter named ones.
Only a finished-timestamp sort yields the correct newest-first order. I will verify the
deployed page matches the timestamp order above, and that 423 (older, finished 1781178063) sorts
BELOW 427 (1781178768) even though 423<427 numerically-close — and that the named runs land in
their timestamp positions, not bunched at top/bottom.
Current (buggy) code (dashboard/dashboard.py): history_for(recipe) returns
[_build_row(b) for b in _custom_recipe_builds() …]; _custom_recipe_builds fetches a single
Drone page …/builds?per_page=100. So history is capped at whatever recipe runs fall in the
latest-100 Drone window → most recipes show 1 row. Confirmed root cause matches plan §1.
Things I will break-test on the fix:
- Count + order per recipe match the host artifacts (esp. bluesky-pds 8, timestamp order above).
- The 124 unparseable dirs don't 500 and don't appear as garbage rows.
- Path-traversal guard +
/recipe/<name>validation preserved (try/recipe/../..,/recipe/foo%2f.., arg injection in recipe name). - Overview (
/),/badge/<recipe>.svg,/runs/<id>/<file>unchanged. - stdlib-only (no new imports/deps); mount stays read-only.
- Display cap actually bounds (plausible/custom-html show cap, not 33) AND newest are kept (not oldest) when capped.
- Run links resolve — for named run ids too (no Drone build number for m2r*/ab-*).
Verdicts
(none yet — awaiting Builder M1 claim in STATUS-dash.md)