feat(ci): flake gate writes one json line per check

[andrewgazelka]

Follow-up to #1084, which merged before its own Flake job finished (this
repository has no required status checks, ENG-10827, so a cancelled gate does
not block auto-merge).

What this adds

flake-gate-results.jsonl in the workspace, uploaded as a CI artifact, one
line per check:

{"attr":"smash-e2e","outcome":"fail","drvPath":"/nix/store/...-hyperion-smash-e2e.drv","seconds":null}

Written from the same arms of the reporting loops that print ok / FAILED /
STALE / excluded, so the machine-readable verdict and the human one cannot
disagree. attr is the flake attribute, not the derivation name, so nothing
downstream has to map hyperion-smash-e2e back to smash-e2e.

An excluded check is recorded by what it did, not by how the gate treats
it: a still-failing exclusion records fail even though it does not fail the
job. Whether this file forgives a check is this file's business and changes
under a consumer.

drvPath, and the gate's only flake load

drvPath comes from one nix eval --raw --apply over the whole checks set.
That is now the gate's only flake evaluation: the per-check realisation probe
takes the derivation path (nix build --max-jobs 0 --builders "" "$drv^*")
instead of the attribute, so 67 probes load no flake at all.

A derivation path is defined at evaluation time even for the 14 checks whose
output path is deferred behind a content-addressed input, which is why it is
the identity the gate can state for every check. Verified that
--max-jobs 0 on a deferred-output derivation answers 1 before it is built and
0 after, without building it.

The realisation itself still goes through the flake attribute rather than the
derivation path, deliberately: 811 paths in run 30500640846 came from
cache.ix.dev, which the flake's nixConfig supplies and a store-path build
would not see.

seconds is null, on purpose

One concurrent nix build means no check has a wall clock to itself.
smash-e2e and bedwars-bow-e2e overlap each other and both overlap the
compile they depend on, so any per-check number would be a share of a clock the
check did not have. Emitting a plausible-looking one would be worse than
emitting none.

Recovering real per-check durations is possible but is a different change:
split the realisation into a dependency phase (one nix build over the union
of the checks' inputDrvs) and a leaf phase (each check's own derivation,
bounded concurrency, individually timed). That gets exact durations and exact
exit codes, at the cost of a bash job pool and a new failure mode where a
broken shared dependency is retried by each dependent leaf. Say the word and I
will do it.

The gate now prints its own total instead:
gate: 67 enforced and 0 excluded checks in <n>s.

Guard

Names are checked at evaluation time to need no JSON escaping, because the
file is assembled with printf rather than jq. Watched it fail:

error: nix/ci/flake-gate.nix writes each check's verdict into a json results file
       with printf, which holds only for names that need no json escaping. These
       do: he said "hi"
       Rename them, or teach the gate to escape a name before it writes one.

Verified

Ran the gate over six real checks on aarch64-darwin (names trimmed to keep it
cheap), green and broken:

• Six passing: six pass lines, schema and values validated by a JSON parser,
  exit 0.
• One deliberately broken (e2e-ports-distinct, via two gates sharing an
  e2eOffsets value), first in the list: it records
  {"attr":"e2e-ports-distinct","outcome":"fail",...} and the five after it
  still record pass. Note the failing run's drvPath differs from the passing
  run's, which is exactly the discriminator the consumer wants: same derivation
  and different outcome means flake, different derivation means the change.

Neither this nor #1084 was checked by CI before landing

Recorded rather than apologised for, so that main's history is readable later.

bc10ddf (#1084) merged at 03:11 on 2026-07-30 with its own Flake job
cancelled at 377 s. This repository has no required status contexts
(ENG-10827), so nothing stopped it. 256a7b1 (#1088) then turned ci, bench
and conventional into workflow_dispatch only, so nothing will trigger on
main again either, and this PR will land the same way.

Both changes are verified, but locally and by hand rather than by a pipeline:
the gate run over six real checks on aarch64-darwin, green and deliberately
broken, plus the drv-path oracle checked against a synthetic deferred-output
derivation, plus the name guard watched failing. What has not happened is
either change running against all 67 checks on a hosted runner in the shape CI
would run it. A manual gh workflow run ci.yml --repo hyperion-mc/hyperion --ref main is how that gets done from here.

This hour is the boundary. Commits before bc10ddf went in under a running
pipeline whatever its state; commits from bc10ddf on did not.