# 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