Summary
data/release-verdict.json reports build.status: "failed" for builds that are still running, with the reason string stating so outright. The dashboard then propagates that into the verdict cards and into "What's degrading?", so https://factory.projectbluefin.io/ currently reads as a total outage while the factory is in fact healthy.
Evidence
From https://factory.projectbluefin.io/data/release-verdict.json, live:
| lane |
verdict |
build.status |
finished_at |
build.reason |
| bluefin-stable |
bad |
failed |
null |
latest publishing run concluded running |
| bluefin-testing |
bad |
failed |
null |
latest publishing run concluded running |
| bluefin-lts-stable |
bad |
passed |
set |
|
| bluefin-lts-testing |
pending |
passed |
set |
|
| dakota-testing |
bad |
failed |
set |
latest publishing run concluded pending |
Three of five lanes are marked failed for not having finished yet. Two of them have finished_at: null, which is a direct signal that the run is still in flight.
Meanwhile the same page's own rolling-7-day panel reports 79 builds, 74 passed, 5 failed, 94% success rate over the same window.
Impact
- 0 of 5 release lanes render "good", so the page reads as a disaster area.
- The error compounds: "What's degrading?" restates each false failure, so one mapping defect produces roughly six alarming rows.
- This is the single largest reason the dashboard looks broken to a visitor.
Suggested fix
Map GitHub Actions conclusions explicitly, and treat a non-terminal run as pending rather than failed:
conclusion === "success" → passed
conclusion === "failure" | "timed_out" | "startup_failure" → failed
status !== "completed", or conclusion null/running/pending, or finished_at === null → pending
ADR 0002's principle that a lane is never inferred good is right and should stand; the inverse also needs to hold, so a lane is never inferred bad purely from incompleteness.
Worth adding a regression test asserting that a run with finished_at: null never yields build.status: "failed".
Context
Found while auditing both dashboards ahead of consolidating project-level status onto https://docs.projectbluefin.io/factory. Filing here since the mapping lives in this repo.
Summary
data/release-verdict.jsonreportsbuild.status: "failed"for builds that are still running, with the reason string stating so outright. The dashboard then propagates that into the verdict cards and into "What's degrading?", so https://factory.projectbluefin.io/ currently reads as a total outage while the factory is in fact healthy.Evidence
From
https://factory.projectbluefin.io/data/release-verdict.json, live:nullnullThree of five lanes are marked failed for not having finished yet. Two of them have
finished_at: null, which is a direct signal that the run is still in flight.Meanwhile the same page's own rolling-7-day panel reports 79 builds, 74 passed, 5 failed, 94% success rate over the same window.
Impact
Suggested fix
Map GitHub Actions conclusions explicitly, and treat a non-terminal run as pending rather than failed:
conclusion === "success"→ passedconclusion === "failure" | "timed_out" | "startup_failure"→ failedstatus !== "completed", orconclusionnull/running/pending, orfinished_at === null→ pendingADR 0002's principle that a lane is never inferred good is right and should stand; the inverse also needs to hold, so a lane is never inferred bad purely from incompleteness.
Worth adding a regression test asserting that a run with
finished_at: nullnever yieldsbuild.status: "failed".Context
Found while auditing both dashboards ahead of consolidating project-level status onto https://docs.projectbluefin.io/factory. Filing here since the mapping lives in this repo.