dtourolle
c5a8502bbb
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 fromff3b8ebby 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 versionff3b8eb. 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