Skip to main content

max / makenotwork

1.3 KB · 27 lines History Blame Raw
1 -- One row per `/rebuild` invocation: tracks a build attempt through its
2 -- lifecycle so a non-TUI caller can poll `GET /runs/{id}` for build status
3 -- instead of inferring it from `/state` — which only ever reflects the last
4 -- *successful* version and so reports stale-green for the whole duration of a
5 -- failing build (the 0.10.2 headless-deploy incident).
6 --
7 -- `version` is denormalized (no FK): a run may fail before a `versions` row
8 -- exists (fetch/checkout/compile error) and we still want its failure
9 -- recorded. `result` is the terminal verdict — 'building' until the pipeline
10 -- settles, then 'passed' | 'failed' | 'aborted'. `phase` is the in-flight
11 -- sub-state ('queued' | 'fetching' | 'compiling' | 'staging' | 'gating' |
12 -- 'done'). Terminal transitions are guarded on `result = 'building'` so the
13 -- first writer (a build-step error, a gate failure, or the task-level catch)
14 -- wins and later writes are no-ops.
15 CREATE TABLE build_runs (
16 id INTEGER PRIMARY KEY AUTOINCREMENT,
17 sha TEXT NOT NULL,
18 version TEXT,
19 phase TEXT NOT NULL DEFAULT 'queued',
20 result TEXT NOT NULL DEFAULT 'building',
21 failure_summary TEXT,
22 started_at TEXT NOT NULL,
23 finished_at TEXT
24 );
25
26 CREATE INDEX build_runs_by_sha ON build_runs(sha);
27