jschoubben
0bbb5c6838
A build result was answered to whoever asked and kept nowhere. So "when did this last build", "why did it fail" and "which machine built what is running" had no answer, and a build nobody was waiting for was reported into the void — which is the same as not reporting it. Failures are recorded too, and that is the point rather than a detail: 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. A build that never learned what it was building keeps the repository, because that is what a person goes and looks at. Recording is idempotent on the correlation id, because a result can arrive twice — as the answer to whoever asked, and on the exchange when nobody was. Two rows would show one build as two, and which is real is not answerable afterwards. The serving control plane now binds `built` as well, so results from builds it did not ask for are kept. It refuses them loudly when it has nowhere to put them rather than dropping them, so the broker's own counters show something arriving that nothing handles. `builds [<module>]` reads it: what happened lately across the mesh, or what has happened to one module — the first asked after something goes wrong, the second when deciding whether to trust something. What was published is kept with the build, so a digest traces back to what made it without holding the manifest twice in a place that can disagree with the first.
45 lines
2.3 KiB
SQL
45 lines
2.3 KiB
SQL
-- 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;
|