Claude
6d4cd91bcc
Make the base docker-compose.yml strictly production-shaped — image: only, no build: — so a production host can only ever pull, never accidentally build (compose gives build precedence for `up --build`/`build`, which mixed the two modes). Local builds move to an explicit, non-auto-loaded overlay. Production: docker compose pull && docker compose up -d Development: docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build Verified with `docker compose config`: base renders image-only (no build) for both services; the dev overlay adds build back (app -> Dockerfile, bot -> bot/Dockerfile). README quick-start updated to the two-file flow. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0114TpmrNW4wNXsHq5CR72jQ
25 lines
783 B
YAML
25 lines
783 B
YAML
# Development overlay — build the app + bot images locally instead of pulling the
|
|
# prebuilt ones from the Gitea registry.
|
|
#
|
|
# The base docker-compose.yml is production-shaped (image: only, no build:), so a
|
|
# production host can never accidentally build — it only pulls. Use this overlay
|
|
# EXPLICITLY for local work (it is not auto-loaded like docker-compose.override.yml
|
|
# would be):
|
|
#
|
|
# docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build
|
|
#
|
|
# Production stays:
|
|
#
|
|
# docker compose pull && docker compose up -d
|
|
#
|
|
# The `image:` tags inherited from the base file double as the local build tags,
|
|
# so a built image and a pulled one are interchangeable.
|
|
services:
|
|
app:
|
|
build: .
|
|
|
|
bot:
|
|
build:
|
|
context: .
|
|
dockerfile: bot/Dockerfile
|