-- What has been built, and what came of it.
--
-- A build result is answered to whoever asked and, until this, kept nowhere. So "when did this
-- module last build", "why did it fail", and "which machine built what is running" had no answer
-- at all -- and a build nobody was waiting for was reported into the void.
--
-- **Failures are rows too.** A failed build that leaves no trace is indistinguishable from one
-- nobody asked for, and the difference is the whole of whether somebody should be looking at
-- something. This is the same rule the host follows about a service that does not exist.

create table build (
    -- The correlation the control plane made when it asked. Not the module name: two builds of
    -- one module can be in flight, and one is not the other.
    id          text        primary key,

    -- What was asked for. Kept even when the build failed before knowing what the module is
    -- called, which is most of the interesting failures.
    repository  text        not null,
    ref         text        not null default '',

    -- What came of it. `module` and `commit` are empty for a build that never got that far.
    module      text,
    commit_hash text        not null default '',

    -- The machine that did it, so a failure about one machine can be told from one about the
    -- source. Not a foreign key to node: a build machine need not be a node the mesh manages,
    -- and a record that vanished when it stopped being one would lose the history.
    built_on    text        not null default '',

    -- Empty when it worked. The builder's own words, because anything this end wrote instead
    -- would put a second explanation between a person and a build log.
    failed      text        not null default '',

    -- What was published, as [{name, kind, reference}]. Kept so a digest can be traced back to
    -- the build that made it without keeping the manifest twice.
    made        jsonb       not null default '[]',

    at          timestamptz not null default now()
);

-- The two questions asked of this table: what happened lately, and what has happened to this
-- module. Neither is answerable quickly by scanning once there is a year of them.
create index build_lately on build (at desc);
create index build_by_module on build (module, at desc) where module is not null;