Tags and Properties for Check-in 394b4efa27
- branch=trunk inherited from [da85dd4acf]
- sym-trunk inherited from [da85dd4acf]
|
2026-07-19
| ||
| 01:09 |
CI: sweep every seeded fuzz target, and bump checkout to v5
Two gaps the first green run exposed. The repository carried 26 fuzz targets that CI never fuzzed. They reached CI only through their fixed-seed smoke tests inside `zig build test`, so the fuzzing investment was half-realized: the targets compiled and ran a handful of canned cases, but nothing swept them. `zig build fuzz` runs one target per invocation, so the new step loops. The target list is read from the step's own usage output rather than kept in the workflow — a target added to fuzz_tests.zig is swept automatically, with no second list to drift. Seed and rounds are fixed (1, 2000), not random: a red run has to be reproducible verbatim on a developer machine. Bare `zig build fuzz` exits non-zero because it is a usage error, so the enumeration tolerates that; every real invocation still fails the job. Verified by running the identical block under bash — 26/26 targets pass at seed 1. src/ci_test.zig moves with it. `fuzz` leaves not_in_ci (its stated reason was that wiring a bounded CI invocation belonged to a later step — that step is this one) and a new ci_parameterized table records it as covered-in-a-loop, carrying the exact anchor that proves the invocation exists. The anchor is verified, not trusted: an entry whose anchor drifts out of the workflow fails like any other gap. That distinction is kept separate from not_in_ci on purpose — conflating 'runs, in a loop' with 'deliberately skipped' is how a step silently stops being covered while a stale excuse keeps the pin green. actions/checkout v4 -> v5 clears the Node 20 deprecation warning the green run reported. check-in: 394b4efa27 user: dmestas tags: trunk | |
|
2026-07-08
| ||
| 21:43 | initial empty check-in check-in: da85dd4acf user: dmestas tags: trunk | |