Battle arena and league improvements - #26
Merged
Merged
Conversation
Schema changes are applied manually on the server now, so nothing in the stack can reach the database: no init container, and a deploy that can only pull images and restart containers. The db-init service is gone from docker-compose.prod.yml and from the deploy build matrix — five images again, not six. docker/db-init/ stays on disk because the local dev stack still uses it to set up a disposable database on `docker compose up`. COMMITS THE INITIAL MIGRATION prisma/migrations/0_init was generated with `migrate diff --from-empty` and is 619 lines of SQL. Without it in the repo there is nothing for `migrate deploy` to replay, and the manual path in DEPLOYMENT.md would have no way to build a schema. Verified against a throwaway Postgres: `migrate deploy` applies it cleanly, `migrate diff --exit-code` then reports 0 (no drift from schema.prisma), and `migrate status` reports up to date. Re-running is a no-op rather than an error. DEPLOYMENT.md SECTION 5 REWRITTEN Now covers installing Node and pnpm on the server, `migrate deploy` for the first run and for later changes, and `migrate status` to check before applying. Two details that would otherwise cost an afternoon: the app images carry no Prisma CLI, so the server checkout is what runs these; and DATABASE_URL in .env.prod points at host.docker.internal, which does not resolve outside a container, so the host command needs localhost. It also steers away from `prisma db push`, which force-converges with no history — a renamed column becomes a drop and recreate. The seed stays documented as destructive rather than recommended. It deletes every problem and test case before inserting three samples, and once a battle references a problem the delete is refused outright. It is for an empty database and a smoke test, nothing more. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Rexial-style rewrite dropped the x-logging anchor and nothing replaced it, so every service fell back to Docker's default json-file driver — which has no size limit. A chatty service, or one stuck in a restart loop, grows its log until the VPS disk is full, and a full disk takes down the whole stack including the services that were healthy. Each of the seven services now caps at 10MB x 3 files, so logs can claim at most ~210MB total. Verified by reading the resolved config rather than the file: every service reports max-size 10m, max-file 3. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.