4 Commits

Include renames

Author	SHA1	Message	Date
dtourolle	9bcc765408	fix(ci): the builder image has no unzip, so the replay tier had no input ... Found by CI itself, on run 1437 -- the first run that ever got far enough to try. Everything ahead of it worked: checkout brought both submodules, v2 pulled and passed its own version assert, and the fixtures resolved at the pinned version. Then: scripts/artifacts/pull_artifacts.sh: line 54: unzip: command not found The replay fixtures ship as a zip in the generic package registry and pull_artifacts.sh unpacks them with unzip. Without it the step exits 127 and the T2 tier has no input -- reported as a missing fixture by the verify step below, which is a missing tool wearing the wrong label. Worth naming why the local rehearsal missed this and CI did not: the rehearsal had the dumps staged in the working tree by hand, so it built and ran the tier without ever executing the script that fetches them. The image was checked against the build, not against the job. Tag v2 -> v3, in all three places, in one commit. TRACES: DP-007 | PR-004	2026-08-31 08:04:43 +02:00
dtourolle	80c23d39d1	fix(ci): sae-builder-cpu could not configure this repository at all ... v1 has no libfftw3. SAE_SCENE_XGB is on by default and pulls the learned scene-boundary detector into result_sink, whose find_library(FFTW3_LIB fftw3 REQUIRED) at CMakeLists.txt:377 runs at CONFIGURE time -- so cmake fails before any target is chosen, and building only `sae_tests` does not get you past it. The image predates the detector; nothing rebuilt it when the detector landed, which is precisely the gap DP-007's own register row records. -DSAE_SCENE_XGB=OFF would also have made the configure pass. It is the wrong fix and worth saying why: CI is the only place these tests run, so a flag that silences a subsystem there silences it everywhere, and the job would have gone green over a detector nobody was compiling. The image's self-check gains a line, because an image that ships a library CMake cannot find the way CMake looks for it is the failure this block exists to catch. FFTW is checked as a bare .so rather than through pkg-config, since find_library is what CMakeLists.txt actually calls -- checking fftw3.pc would pass on an image whose libfftw3.so was absent. Tag bumped v1 -> v2 here, in build_builder_image.sh and in the workflow's run-time assert, in one commit, as this image's contract requires. v2 is built and published. Rehearsed in the image before pinning it: configure, build and 151 tests now run. TRACES: DP-007 | PR-004	2026-08-30 22:42:15 +02:00
dtourolle	c5a8502bbb	ci(tests): publish what the job was told to pull, and pin it ... DP-007's row says the builder image is "pinned by tag in the Gitea container registry". The tag was pinned; the image was never pushed. Every run since the workflow landed died at "Error response from daemon: manifest unknown" before a single step ran, so the tier this workflow exists to execute has still never executed. sae-builder-cpu:v1 is now in the registry, built from ff3b8eb by scripts/ci/build_builder_image.sh and reporting SAE_BUILDER_VERSION=v1, which is what the job's own assert-the-image step demands. The v1-ff3b8eb audit tag went with it. Behind that, the same absence one layer down: no replay-fixtures package existed either, so "Verify the fixtures actually arrived" would have failed next. tests/fixtures/dumps is now published at version ff3b8eb. Which makes the `latest` here worth removing rather than keeping. Two reasons, either sufficient. It is the same argument DP-007 already makes about the image tag -- a dump is an input to the tests, so a re-upload under a moving `latest` retroactively changes what an earlier green build proved. And `latest` was the only thing in this job that wanted a credential: package downloads are anonymous while the repo is public, and only resolving `latest` needs a token for the list endpoint. No GITEA_TOKEN secret is configured on this repo, so that step could never have resolved `latest` even once the image existed. Pinning deletes the dependency instead of documenting it. The failure message below it said the step "needs GITEA_TOKEN to resolve 'latest'"; it now says to check the pinned version still exists, which is the thing that can actually go wrong -- pull_artifacts.sh warns and continues on a missing version rather than failing, which is why that verify step is there at all. TRACES: DP-007 | PR-004	2026-08-30 22:09:02 +02:00
dtourolle	fd078c399f	ci(tests): actually run the tier the verification strategy is built on ... docs/requirements.md describes four verification tiers and argues that T1 (functor unit) and T2 (replay) are "the only tiers that can exist in CI at all". The traceability gate then reports a CI-scope coverage fraction over exactly those tiers. Nothing ran them: the only workflow was the gate itself, which reads source comments, and SAE_BUILD_TESTS defaults to OFF. "Covered" meant a TRACES tag existed in a file. That is the same failure the gate's own config warns about one level up -- counting a test that cannot run -- and the gate cannot see it, because a tag is all a static reader has. Runs in the pinned DP-007 CPU builder image, which the image script already expected this workflow to exist (it names unit-tests.yml and asserts its tag). Nothing here calls a model: T1 constructs node functors directly and T2 replays a precomputed dump, so the GPU-free N100 runner is sufficient by construction rather than by concession. Two deliberate hard failures. A missing replay fixture fails the job instead of skipping, because pull_artifacts.sh warns-and-continues and a T2 test whose input never arrived must not look like a pass. And the image reporting a tag other than the pinned one fails rather than building against an unknown toolchain. It found a real bug on its first run: see the preceding commit. ctest runs each case in its own process, which turned a 1-in-4 heap corruption from noise in the aggregate binary into a reproducible failure. TRACES: DP-007 | PR-004	2026-08-05 15:17:17 +02:00