fix(ci): drop postgres service host-port mapping to end 5432 collision (#174) #177
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/174-ci-postgres-host-port"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Root cause (from the runner log for the failing push run)
The
backendjob'spostgres:16service publishedports: - 5432:5432, binding port 5432 on the runner host. That host already runs other Postgres containers on 5432, so the service container failed to start before any test ran — a fast (~10s) job failure. Because host-port availability is a race, it looked like intermittent "push fails, PR passes" flakiness (#174); it was really whichever run happened to hit an already-bound 5432.Fix
Remove the host-port mapping. It was unnecessary — the job connects to the DB by its network alias (
postgres:5432, viaDATABASE_URL/TEST_DATABASE_URL), not via the host, exactly as the job's own comment already stated ("the ports: mapping binds the runner host, which the job container cannot see"). Dropping it eliminates the collision entirely, for every event type.Nothing else changes: the three DB URLs still target
@postgres:5432, and the service keeps itspg_isreadyhealthcheck.Validation
ci.ymlparses as valid YAML;5432:5432gone; DB URLs still use thepostgresservice alias.backendjob exercises the change (migrations + full pytest against the service with no host binding).push→mainrun is the real confirmation that the collision is gone; I'll verify it before closing #174.Refs #174
🤖 Generated with Claude Code
The backend job's postgres:16 service published `5432:5432` on the runner host. The runner host already has other Postgres containers bound to 5432, so the service container failed to start before any test ran: Bind for 0.0.0.0:5432 failed: port is already allocated which surfaced as a fast (~10s) job failure. The mapping is unnecessary: the job connects to the DB by its network alias (postgres:5432, via DATABASE_URL), not the host — as the job's own comment already noted. Removing the host binding eliminates the collision. Root cause of #174 (push-to-main runs failing while PR/dispatch passed was a timing coincidence of which runs hit an already-bound host 5432). Refs #174