Lucas RayanandClaude Opus 5
f117e1e9d7
The first deployments died building on the target: four images, and the webmail build alone was enough to sink it on a small arm64 host - the build step was killed with no BuildKit error, which is what an exhausted or overloaded machine looks like from the outside. The images already exist. CI publishes all four to GHCR for amd64 and arm64 on every merge, and they are the ones the suite ran against, so rebuilding them on the deploy target is slower, heavier and less trustworthy than pulling them. docker-compose.yaml therefore carries no build definitions, and docker-compose.build.yaml is the overlay that adds them for local development and for CI - which does have to exercise the branch rather than the published images. Both paths were run before committing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
22 lines
667 B
YAML
22 lines
667 B
YAML
# Development overlay: builds the images from source instead of pulling them.
|
|
#
|
|
# Production deploys pull what CI already built and tested, so the compose file
|
|
# proper carries no build definitions - rebuilding four images on the target
|
|
# host is slow and, on a small server, the webmail build is enough to fail the
|
|
# deployment outright.
|
|
#
|
|
# Use it explicitly:
|
|
# docker compose -f docker-compose.yaml -f docker-compose.build.yaml up --build
|
|
services:
|
|
auth:
|
|
build: { context: ./services/auth }
|
|
|
|
storage:
|
|
build: { context: ./services/storage }
|
|
|
|
protocols:
|
|
build: { context: ./services/protocols }
|
|
|
|
web:
|
|
build: { context: ./services/webmail }
|