ci: make both workflows able to run at all #1
Merged
dtourolle
merged 6 commits from 2026-09-03 18:19:42 +00:00
ci/green-the-runner into master
6
Commits
| 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
|
||
|
dtourolle
|
3966e19a83 |
test: two tests still describe the registry as it was before 1477c53
Both failed the first time CI was able to run this suite, and neither is
a new break. They assert semantics that two deliberate changes replaced,
and nothing noticed because nothing had ever executed them.
|
||
|
dtourolle
|
5ce6394416 |
chore: update KPN — diagnostics.hpp includes the <vector> it uses
af9da7d on top of 5375ab4, and the reason it exists is this repository. kpn/diagnostics.hpp declares NetworkSnapshot with two std::vector members and has never included <vector>. It compiled everywhere we build because something earlier in each translation unit dragged the definition in first. src/benchmark.hpp includes <kpn/diagnostics.hpp> before its own <vector>, and under Debian 12 / GCC 12 -- the CI image, and nothing we develop on -- nothing supplies it, so the two members fail to declare and every later use of .nodes or .channels fails after them. The errors all name benchmark.hpp, so it reads as our bug until you look at the first line of compiler output rather than the last. This bump also crosses the four perf/phase0-harness commits between 5375ab4 and the pin, which is a larger move than a header fix and worth being explicit about. Checked rather than assumed: the two tests failing in CI fail identically with the pin at 771b9f8 plus the include fix alone, so they are not this bump's doing. The perf work changes the scheduler and pool; the failures are tracker extinction-window logic and are reachable with no pool at all. Also found while checking KPN's public headers standalone under GCC 12, and NOT fixed there: network.hpp names IChannelProbe (channel.hpp:557) without including channel.hpp -- the same latent bug, waiting for the same kind of consumer. web_debug.hpp needs httplib.h, which is an optional external dependency and not a defect. |
||
|
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 |
||
|
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 |
||
|
dtourolle
|
fb4e4d4abc |
ci(traceability): the job container is where act_runner looks for node
The traceability job has been failing since it was written, and never on anything it checks. It declared no `container:`, so it ran in the runner's default image, which has no node; act_runner executes JS actions with the node it finds inside the job container, and both actions/checkout and upload-artifact are JS. The job died at "Cannot find: node in PATH" before the repository was checked out, and every later step then failed on an empty working tree -- the summary step's "head: cannot open 'docs/traceability.md'" is that, not a missing report. node:20-bookworm, and the choice is not arbitrary: node is the part with no workaround, while Debian 12 already carries python3.11 (tomllib, so the stdlib-only extractor reads traceability.toml) and git (for the pull_request diff step). Nothing in it names this repo, so the file stays copyable into the other two components unedited, which its header claims and this commit keeps true. The kpnpp-builder and jellytau-builder images bake node in for exactly this reason, and Dockerfile.builder-cpu says so in a comment. That knowledge just had not reached the one job with no image of its own. Second failure behind the first: the jray-project submodule was pinned by SSH URL. The runner has no key, so `submodules: recursive` could not have fetched the extractor even with node present. https, like the KPN submodule beside it. Gate and static check both pass locally on this tree -- 42/72 traced, 73.7% in CI scope, 0 orphans, 0 bare-cosine violations -- so what CI reports next is a fact about CI, not about the tree. |