CI: per-run Postgres container name and ephemeral port (#165) #166

Merged

claude-bot merged 1 commit from fix/ci-postgres-collision into main

2026-08-01 02:50:59 +00:00

claude-bot commented

2026-08-01 02:24:30 +00:00

Contributor

Closes #165.

Problem

When two PRs' CI runs overlap on the shared runner host, both go red: every job starts with docker rm -f ci-postgres, force-removing the concurrent run's live database mid-suite, and the fixed -p 5432:5432 publish would collide anyway. This happened to #163/#164 tonight (runs 141/142, started two minutes apart, both failed; both branches passed the full suite + ruff on the dev server and went green on solo reruns).

Change

Container is named ci-postgres-${GITHUB_RUN_ID}; the pre-clean rm -f and the always() teardown are scoped to that name, so a job can only ever remove its own (possibly stale-from-a-crashed-rerun) container.
The host publish is now ephemeral (-p 5432 → random free host port). The wait-and-detect step discovers the mapped port via docker port and exports PG_PORT alongside PG_HOST; the migration and postgres-tier steps use both. Container-side candidates (container name, network IPs) still connect to 5432 directly, so both the containerized-job and host-job paths keep working.

Verification

YAML parses; the detection script's candidate order is unchanged in spirit (container IPs → name → host fallbacks). This PR's own CI run exercises the whole path — and any future overlapping runs are the real test.

🤖 Generated with Claude Code

Closes #165. ## Problem When two PRs' CI runs overlap on the shared runner host, both go red: every job starts with `docker rm -f ci-postgres`, force-removing the concurrent run's live database mid-suite, and the fixed `-p 5432:5432` publish would collide anyway. This happened to #163/#164 tonight (runs 141/142, started two minutes apart, both failed; both branches passed the full suite + ruff on the dev server and went green on solo reruns). ## Change - Container is named `ci-postgres-${GITHUB_RUN_ID}`; the pre-clean `rm -f` and the `always()` teardown are scoped to that name, so a job can only ever remove its own (possibly stale-from-a-crashed-rerun) container. - The host publish is now ephemeral (`-p 5432` → random free host port). The wait-and-detect step discovers the mapped port via `docker port` and exports `PG_PORT` alongside `PG_HOST`; the migration and postgres-tier steps use both. Container-side candidates (container name, network IPs) still connect to 5432 directly, so both the containerized-job and host-job paths keep working. ## Verification YAML parses; the detection script's candidate order is unchanged in spirit (container IPs → name → host fallbacks). This PR's own CI run exercises the whole path — and any future overlapping runs are the real test. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit

2026-08-01 02:24:30 +00:00

CI: per-run Postgres container name and ephemeral port (#165 )

CI / test (pull_request) Successful in 4m53s

Details

2469a1f3af

Two PRs' CI runs overlapped on the shared runner and both went red: every
job began with `docker rm -f ci-postgres`, killing the concurrent run's
live database mid-suite, and the fixed -p 5432:5432 publish would have
collided anyway.

The container is now named ci-postgres-${GITHUB_RUN_ID} (pre-clean and
teardown scoped to it) and publishes an ephemeral host port; the
wait-and-detect step discovers the mapped port via `docker port` and
exports PG_PORT alongside PG_HOST for the migration and postgres-tier
steps. Container-side candidates (container name / network IPs) still
connect to 5432 directly.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

claude-bot merged commit ddae711d3d into main

2026-08-01 02:50:59 +00:00

claude-bot deleted branch fix/ci-postgres-collision

2026-08-01 02:50:59 +00:00

claude-bot referenced this pull request from a commit

2026-08-01 02:51:00 +00:00

Merge pull request 'CI: per-run Postgres container name and ephemeral port (#165)' (#166) from fix/ci-postgres-collision into main