Locally, phonenumbers' largest generated geodata files (~900KB of literal
dict data) compile in ~0.1s each; the build host still timed out at 300s+
on a single one of the 29 such files -- a ~3000x gap no reasonable timeout
bump reliably survives across all of them. That gap points to something on
the build host itself (cross-arch emulation or memory pressure), not a file
that's merely slow. Turning bytecode compilation off trades a slow, flaky
build for a slower first import per container boot (--preload/prefork pay
that once, not per request) until the underlying host issue is found.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
uv sync --compile-bytecode enforces a hardcoded 60s-per-file cap, and
phonenumbers' generated geodata/data*.py files (large literal dicts, not
slow code) blow past it on a slower builder even though nothing's actually
hung -- widen the cap via UV_COMPILE_BYTECODE_TIMEOUT rather than dropping
UV_COMPILE_BYTECODE entirely, which would just move that same compile cost
to every cold container start instead of paying it once at build time.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Large uncommitted body of work accumulated across sessions on this branch --
committing as a checkpoint so it's tracked and future worktree-isolated agents
see the real codebase instead of a stale ancestor commit. Covers the
management app's dedicated Tailwind theme and templates, the club onboarding
requirement/signup workflow (club/services/onboarding.py, requirement/status
models, sign-up dashboard), fee/status auto-activation decoupling, referee
management, and the new events calendar grid service layer.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ECGMEwrc2k4D8VQuwjstj9
The Docker image's CSS build stage only COPYed assets, templates,
controlpanel and billing before running npm run build -- management
and club were never in that build context, even though assets/app.css's
@source lines already listed (or, for club, should have listed) them.
Any utility class used only inside those two apps' templates was
silently absent from the compiled static/css/app.css in production,
while working fine locally since `npm run build` there scans the full
checkout rather than a Docker COPY subset.
This is what made management/home.html's md:grid-cols-5 (the dashboard
KPI grid fix from earlier) never take effect on the server: the class
just didn't exist in production's CSS, so the grid silently fell back
to sm:grid-cols-2 at every width.
Verified by reproducing the exact Docker build context outside Docker:
md:grid-cols-5 is absent from the compiled CSS with the old COPY list,
present with the new one.
club/templates has no live bug today (everything it uses is also used
elsewhere), but it's the same gap and cheap to close before it bites.
- gunicorn: 3 workers -> 2 (this workload isn't CPU-bound per
DEPLOYMENT.md's own sizing), add --preload so workers share
immutable memory via copy-on-write instead of each independently
importing Django, add --max-requests so a worker that renders a
WeasyPrint invoice doesn't carry that memory forever.
- Postgres: trim shared_buffers/max_connections from the image
defaults (128MB/100), sized for a ~0.2GB dataset instead.
- Redis: cap with --maxmemory as a ceiling, not a saving.
/app/media didn't exist in the image, so the media_data volume had
nothing to copy ownership from on first mount — Docker created the
mount point owned by root, and the container runs as rosterchief.
Uploads then failed with PermissionError. Create the directory
before the chown so it carries the right ownership into the volume.
gunicorn 26's control server creates a socket in $HOME. The app user has no home
directory, so every boot logged "Permission denied: /home/rosterchief" — harmless
but noisy. /app is the workdir and already owned by the app user.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The build died at `uv sync`: django-lucide is our fork, declared as a git source
and pinned by the lock to a commit, so uv shells out to `git` to fetch it — and
python:3.14-slim has no git.
Installing git in the runtime image would have fixed it and left a build tool, plus
its dependency tree, in production for the sake of one package that is already
vendored into the venv by then. So the virtualenv is now built in a stage that has
git, and the finished .venv is copied into a runtime stage that does not. Same base
image, so the compiled wheels inside it stay ABI compatible.
Also drops the second `uv sync`, which installed the project itself: there is no
[build-system] and rosterchief is not a package — gunicorn imports it from the
working directory, exactly as it does locally.
Unverified end to end: still no container runtime on this machine.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
One server now, the same image and env vars for many later: point
DJANGO_DATABASE_URL / DJANGO_REDIS_URL at central services, set a bucket, drop the
db and redis services, run several web containers behind a load balancer. No code
changes.
The wildcard certificate is what shapes this. Subdomain tenancy needs
*.rosterchief.app, and Let's Encrypt will not issue a wildcard over HTTP-01 -- only
DNS-01 -- so Caddy is built with a DNS provider plugin and needs an API token. That
single constraint is why the proxy is Caddy rather than the usual nginx+certbot.
The image apt-installs libpango and friends, which is what WeasyPrint binds to. The
PDF invoices that cannot render on a Mac without Homebrew work in the container by
construction.
Migrations are NOT run by the entrypoint: with more than one web container they
would race, and a starting gunicorn worker is a bad place to discover a failed
migration. Deploy runs them once, explicitly.
Two things the local build check caught, either of which would have failed the
image build at collectstatic (manifest storage treats a missing referenced file as
fatal):
- chart.js ended with a sourceMappingURL pointing at a .map we never vendored.
Stripped, with an npm script so re-vendoring cannot bring it back.
- The Tailwind INPUT file lived at static/src/app.css, inside the served static
tree, so collectstatic collected it and then choked on its @import "tailwindcss".
It belongs outside: it is a build input, not an asset. Now assets/app.css.
Verified locally under gunicorn + WhiteNoise + manifest storage: pages serve and
the CSS comes back hashed. The image itself is unverified -- there is no container
runtime on this machine.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
