Skip to content

Battle arena and league improvements - #24

Merged
TheCodeHeist-Coder merged 2 commits into
mainfrom
battle-arena-and-league-improvements
Sep 12, 2026
Merged

TheCodeHeist-Coder merged 2 commits into
mainfrom
battle-arena-and-league-improvements

Conversation

@TheCodeHeist-Coder

Copy link
Copy Markdown
Owner

No description provided.

TheCodeHeist-Coder and others added 2 commits September 13, 2026 03:24
THREE COMPOSE FILES -> TWO

The middle file was the one to lose. dev.yml covered daily work and
prod.yml covered deployment; the old docker-compose.yml only covered
"run the production build on a laptop with containerised Postgres" —
a convenience, not a necessity.

Rather than delete it and leave the dev stack behind an -f flag, the
dev stack now IS docker-compose.yml. Development happens many times a
day and gets the default filename; deployment is rare and deliberate
and spells out its file:

  docker compose up --build                        # develop
  docker compose -f docker-compose.prod.yml up -d  # deploy

The dev stack keeps the project name `spidder-dev`, distinct from
prod's `spidder`, so a local stack and a deployment on one machine
never adopt each other's containers or volumes.

What is genuinely gone: running the production images locally against
containerised Postgres and Redis. prod.yml expects both on the host, so
it will not stand up on a laptop unedited.

DEPLOYMENT DOCS UNTRACKED

DEPLOYMENT.md and DEPLOY-WALKTHROUGH.md are gitignored and removed from
the index — `git rm --cached`, so both stay on disk. .gitignore alone
would have done nothing: git keeps tracking what is already in the
index.

Every reference to them is rewritten rather than left dangling, since
they will not exist in a fresh clone — the host-firewall note that lived
only in prod.yml's pointer is now written out in prod.yml itself.

Both files verified with `docker compose config`; the bare command
resolves to the .dev Dockerfiles. deploy.yml touches only prod.yml and
is unaffected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The file opened with 70 lines of prose and three YAML anchors, so the
first actual service appeared on line 112. Reading any one service meant
scrolling back up to three separate x- definitions to find out what its
environment, extra_hosts and logging really were.

Now `services:` is on line 11 and every service states its own config in
full. The anchors are gone: x-app-env, x-host-access and x-logging were
DRY but indirect, and this file is read far more often than it is edited.

Reference prose moved to the bottom under SERVER SETUP — host Postgres
and Redis config, secrets, images, and the db-init risk. Still there for
whoever needs it, no longer between the reader and the services.

The cost is real and deliberate: the shared env block is now repeated
across four services, so a change to DATABASE_URL means four edits
instead of one. Worth it for a file whose job is to be understood at a
glance during a deploy.

Verified with `docker compose config` before and after: every service
resolves byte-identically. The only difference in the rendered output is
the x- definitions no longer appearing, which is the point.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@TheCodeHeist-Coder
TheCodeHeist-Coder merged commit 285a17a into main Sep 12, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant