patrick/chitai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: tell the tests where the database actually is
ci / backend (push) Failing after 1m16s
Details
ci / frontend (push) Successful in 1m58s
Details

Browse Source 
DOCKER_HOST only decides which daemon creates the container; the address the
test dials comes from POSTGRES_HOST, which defaults to the job container's own
loopback. Setting one without the other still times out.
This commit is contained in:
patrick
2026-08-18 00:49:41 -04:00
parent 5176dfcb77
commit 412a73cedf
2 changed files with 31 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ci-release-pipeline.md
+18 -8
View File
@@ -105,14 +105,24 @@ the workflow.
volume), or run the runner in host mode. The dind sidecar is the safer of the two — mounting the
host socket into job containers gives any workflow root on the runner host.
**Reachability is a separate question from availability, and it bit us.** Mounting the host
socket into a containerised job gives it a working daemon, and `pytest tests/` still fails with
`Service 'pytest_databases_postgres' failed to come online`: the container starts fine, but its
published port lands on the *host's* network namespace while the test process looks for it on
the job container's loopback. `pytest_databases/docker/__init__.py` picks the address from
`DOCKER_HOST` — `127.0.0.1` when it is unset or `unix://`, otherwise the hostname out of
`tcp://host:port`. So a TCP `DOCKER_HOST` is what makes the sibling container addressable, and
the value must include the port or it raises rather than falling back.
**Reachability is a separate question from availability, and it bit us.** A containerised job
with a working daemon still fails `pytest tests/` with
`Service 'pytest_databases_postgres' failed to come online`: the database container starts
fine, but its published port lands on the daemon's network namespace while the test process
looks for it on the job container's loopback.
Two variables control two different things, and both must be set:
| Variable | Decides | Read by |
| --- | --- | --- |
| `DOCKER_HOST` | which daemon the container is created on | `_service.py` `get_docker_host()` |
| `POSTGRES_HOST` | the address the test then connects to | `docker/postgres.py` `postgres_host`, default `127.0.0.1` |
Setting only `DOCKER_HOST` is not enough — `DockerService.run()` takes `container_host` as a
plain argument defaulting to `127.0.0.1`, and the postgres fixture fills it from
`POSTGRES_HOST`. (There *is* a `DOCKER_HOST`-parsing helper in `pytest_databases`, but it is
`_get_docker_ip()` on the docker-compose class in `docker/__init__.py` and no part of this
path uses it. Do not be misled by it, as I was.)
Until the runner grows its own sidecar, `ci.yml`'s backend job carries a `docker:dind` service
of its own with `DOCKER_HOST: tcp://docker:2375`. That needs the runner to permit