3 Commits

Include renames

Author	SHA1	Message	Date
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