jschoubben
a69a832248
A module's dependencies are one relation in the catalogue — stands-on, packages, built-by, declared — answered by one call. A merge takes what moved and everything reachable from it, sorts the set into tiers (a code dependency in the same tier, a build dependency after its base is built, a runtime dependency after the build machine is built and running; the build machine's own base comes first, built by the one that runs), writes the plan to the store, asks the first tier and returns. Every outcome advances the plan; a ticker advances what outcomes cannot; a controller replaced mid-plan resumes it. status lists open plans and names one that has waited too long.
20 lines
1021 B
SQL
20 lines
1021 B
SQL
-- A merge produces a tiered plan the mesh keeps (novox/hq ADR 0162): what the merge changed and
|
|
-- everything standing on it, sorted into tiers, each module's state, and the tier the plan is at.
|
|
-- Kept so a controller replaced mid-plan resumes it, and so `status` can say what a merge still
|
|
-- waits for.
|
|
create table release_plan (
|
|
id text primary key,
|
|
repository text not null,
|
|
commit_hash text not null,
|
|
created timestamptz not null default now(),
|
|
updated timestamptz not null default now(),
|
|
-- building: a tier's builds are asked; rolling: the tier is built and the machines are applying
|
|
-- what a later tier needs running; done; failed.
|
|
state text not null,
|
|
tier int not null default 0,
|
|
tiers jsonb not null,
|
|
modules jsonb not null,
|
|
note text not null default ''
|
|
);
|
|
create index release_plan_open on release_plan (created) where state in ('building', 'rolling');
|