Hartmut
0ef9add935
CI / Architecture Guardrails (push) Successful in 3m13s
CI / Typecheck (push) Successful in 3m39s
CI / Lint (push) Successful in 4m15s
CI / Unit Tests (push) Successful in 7m10s
CI / Build (push) Successful in 7m8s
CI / E2E Tests (push) Successful in 4m50s
CI / Fresh-Linux Docker Deploy (push) Successful in 5m1s
CI / Release Images (push) Successful in 5m10s
Nightly Security / Dependency Audit (push) Successful in 1m38s
CI / Assistant Split Regression (push) Successful in 5m18s
The app container is attached to both `default` and `gitea_gitea` networks. Both have a container answering to "postgres" (ours on default, Gitea's core on gitea_gitea). Docker's embedded DNS returns IPs from all attached networks, so the app startup script's `prisma db push` and the seed script's `prisma.user.count()` cached different IPs and hit different postgres instances. The seed then saw "table public.users does not exist" even though `/api/health` reported db:ok. Override DATABASE_URL and REDIS_URL in docker-compose.ci.yml to use the unique compose container names (capakraken-postgres-1, capakraken-redis-1) so resolution is unambiguous. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
43 lines
2.1 KiB
YAML
43 lines
2.1 KiB
YAML
# CI override for docker-deploy-test.
|
|
#
|
|
# The dev compose bind-mounts `.:/app` so edits are live during `pnpm dev`.
|
|
# Under act_runner (docker-outside-of-docker on Gitea), the host docker
|
|
# daemon cannot see the job container's /workspace/... path, so the bind
|
|
# mount resolves to an empty directory inside the app container and masks
|
|
# everything the Dockerfile copied in — including tooling/docker/app-dev-start.sh.
|
|
#
|
|
# Result: `sh: cannot open ./tooling/docker/app-dev-start.sh: No such file`.
|
|
#
|
|
# This override strips all bind mounts from the `app` service so the image
|
|
# runs against its baked-in copy of the repo.
|
|
services:
|
|
app:
|
|
volumes: !reset []
|
|
# Attach only the app to gitea_gitea so the act_runner job container
|
|
# (which lives on gitea_gitea) can reach the compose app by service name.
|
|
# Do NOT attach postgres/redis here — doing so causes hostname collisions
|
|
# with other containers already on gitea_gitea (Gitea core + concurrent
|
|
# job service containers all answer to "postgres"), producing split-brain
|
|
# where different clients hit different DBs. The app talks to postgres/
|
|
# redis by service name on the internal compose network, which works
|
|
# regardless of gitea_gitea.
|
|
networks:
|
|
- default
|
|
- gitea_gitea
|
|
# Even with postgres NOT attached to gitea_gitea, the app container's DNS
|
|
# for "postgres" still returns ambiguous results: Gitea's core stack on
|
|
# gitea_gitea has its own container named "postgres", and Docker's
|
|
# embedded DNS resolves bare names against ALL attached networks. Result:
|
|
# the app's startup script's `prisma db push` and the seed script's
|
|
# `prisma.user.count()` may cache different IPs and end up on different
|
|
# DBs (one with our schema, one without — Gitea's). Pin DATABASE_URL and
|
|
# REDIS_URL to the unique compose container names so resolution is
|
|
# unambiguous regardless of attached networks.
|
|
environment:
|
|
DATABASE_URL: postgresql://capakraken:capakraken_dev@capakraken-postgres-1:5432/capakraken
|
|
REDIS_URL: redis://capakraken-redis-1:6379
|
|
|
|
networks:
|
|
gitea_gitea:
|
|
external: true
|