ci: drop host port mapping for Mongo service container #8

Merged

alvaro merged 1 commit from ci/fix-mongo-service-port-collision into main

2026-07-19 00:04:12 +00:00

alvaro commented

2026-07-19 00:03:16 +00:00

Owner

Problem

The test job fails on the runner (Solaria) with:

failed to start container: Error response from daemon: failed to set up container networking:
  driver failed programming external connectivity on endpoint ... :
  Bind for 0.0.0.0:27017 failed: port is already allocated

(run 128, job test, task 269.)

Cause

The services.mongo block mapped ports: 27017:27017, which publishes the container port to host port 27017. That host port is already taken (by a mongod running on the runner host itself), so Docker can't bind it, the service container fails to schedule, the job network is torn down, and the whole test job aborts before any test runs.

This is host-specific, not code-specific — it hits every PR, including #6 (Phase A1). My branch reproduces all four jobs green locally.

Fix

Drop the ports: mapping. The job container doesn't need it: it reaches Mongo over the job's internal network via the service hostname, and MONGODB_URI=mongodb://mongo:27017 already uses mongo (not localhost). The host port mapping was both unnecessary and the source of the collision.

This is the idiomatic GitHub/Forgejo Actions pattern for service containers — only map a host port when an external client needs in, which isn't the case here.

Verification

YAML re-validated locally.
Not possible to fully reproduce the runner's Docker networking locally, but the change is minimal and matches the documented service-container pattern. The proof will be the next CI run on this branch.

Side notes from the run log (not addressed here)

'runs-on' key not defined in Lint and Build/clippy / format — the act runner warns about runs-on: docker (legacy form). These are warnings, not the failure; leave for a separate cleanup if desired.
The workflow comment claims the job "skips gracefully if Mongo is unreachable" — that covers Mongo being down, not the service container failing to schedule. Worth rewording another time.

Once merged, re-run #6's CI to confirm the test job goes green.

## Problem The `test` job fails on the runner (Solaria) with: ``` failed to start container: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint ... : Bind for 0.0.0.0:27017 failed: port is already allocated ``` (run 128, job `test`, task 269.) ## Cause The `services.mongo` block mapped `ports: 27017:27017`, which publishes the container port to **host** port 27017. That host port is already taken (by a `mongod` running on the runner host itself), so Docker can't bind it, the service container fails to schedule, the job network is torn down, and the whole `test` job aborts before any test runs. This is host-specific, not code-specific — it hits **every** PR, including #6 (Phase A1). My branch reproduces all four jobs green locally. ## Fix Drop the `ports:` mapping. The job container doesn't need it: it reaches Mongo over the job's internal network via the service hostname, and `MONGODB_URI=mongodb://mongo:27017` already uses `mongo` (not `localhost`). The host port mapping was both unnecessary and the source of the collision. This is the idiomatic GitHub/Forgejo Actions pattern for service containers — only map a host port when an *external* client needs in, which isn't the case here. ## Verification - YAML re-validated locally. - Not possible to fully reproduce the runner's Docker networking locally, but the change is minimal and matches the documented service-container pattern. The proof will be the next CI run on this branch. ## Side notes from the run log (not addressed here) - `'runs-on' key not defined in Lint and Build/clippy` / `format` — the act runner warns about `runs-on: docker` (legacy form). These are warnings, not the failure; leave for a separate cleanup if desired. - The workflow comment claims the job "skips gracefully if Mongo is unreachable" — that covers *Mongo being down*, not *the service container failing to schedule*. Worth rewording another time. Once merged, re-run #6's CI to confirm the test job goes green.

alvaro added 1 commit 2026-07-19 00:03:16 +00:00

ci: drop host port mapping for Mongo service container

Lint and Build / format (pull_request) Successful in 35s

Details

Lint and Build / clippy (pull_request) Successful in 1m40s

Details

Lint and Build / build (pull_request) Successful in 3m43s

Details

Lint and Build / test (pull_request) Failing after 2m41s

Details

aa115e6e73

The test job failed on the runner with:
  Bind for 0.0.0.0:27017 failed: port is already allocated

because the services.mongo ports: 27017:27017 tries to claim host port
27017, which is occupied (mongod on the runner host). The job container
doesn't need the host mapping — it reaches Mongo over the job's internal
network via the service hostname (MONGODB_URI=mongodb://mongo:27017).
Drop the ports block so the service container schedules cleanly.

This unblocks all PRs, including #6 (Phase A1).