docs(gitea-runner): vh/albok green on the nh3-docker runner; its CI was slow fsync, not a hang

2026-10-12 23:25:09 -07:00
parent 9f833b2e90
commit 499678979a
2 changed files with 8 additions and 1 deletions
@@ -62,6 +62,13 @@ Its config is `conf/config.nh3-docker.yaml`, tighter than ana-docker's because n
 (~1,234 tests) took 4m45s, against 14m17s on ana-docker in run 11033. That is one run each, at different times of
 day, so read it as a ballpark. The Postgres service, apt and npm all worked without the socket.

+**Second repo: vh/albok** (test job moved at 27d2bb5). Green as of run 11051 (2026-10-12 2312): 1,415 passed in
+9m43s, a job of 11m29s. ⚠ **Correction to infra-ops's 10-12 diagnosis:** albok's CI was never a hanging test. The 169
+service tests fsync their journal and stores on every test: they take 57 s on a laptop and took over 25 min on
+ana-docker, and pytest-timeout never fired. The 4 GiB job cap here then exposed a real bug: a chromadb thread leak,
+26,710 threads / 3.2 GB at peak, and EAGAIN at test 1,273. albok fixed it with a conftest. Note also that job
+containers run as root, so tests relying on `chmod 0` must skip.
+
 A job that needs docker inside it (buildx and the like) cannot run here; keep those on `pfi-fleet`. ⚠ nh3-docker's
 vCPU has no AVX2 either, so CPU-bound torch tests are no faster here. This runner fixes the disk, not the CPU.