revert(docker-compose): keep the cms services the contract tests require
Gitea Actions Runner Test / test-job (push) Successful in 2s
CI / check (push) Successful in 30s
CI / tests-integration (push) Successful in 1m43s
CI / tests-unit (push) Successful in 1m44s
CI / tests-ui (push) Successful in 2m34s
CI / preflight (push) Skipped
CI / deploy (push) Successful in 2m3s

The previous commit removed the `cms` and `cms-green` services from
docker-compose.yml. That was overreach and it broke two tests:

- src/lib/docker-build-contract.test.ts asserts the compose build passes
  NEXT_DEPLOYMENT_ID: ${CMS_RELEASE:-unknown}, so a compose-built image
  carries its release id.
- scripts/proxy-config.test.mjs resolves `docker compose config` and asserts
  the `cms` service's host networking, volumes, healthcheck and image tag.

Both encode that docker-compose.yml is a maintained deployment surface, not a
leftover. Removing it was not my call to make while fixing a deploy.

Restored verbatim. The stray container that actually blocked port 3002 is
already gone, and nothing recreates it: there is no systemd unit or pm2
ecosystem that runs `docker compose up`, and `restart: unless-stopped` only
applies to a container that still exists. So the blocker is resolved by the
container removal alone, and compose stays intact for manual and reviewed use.
This commit is contained in:
openhands committed 2026-10-03 18:51:06 +02:00
1 parent c8b3054527
commit f705c67fc7
1 file changed
+49 -14
+49 -14
View File
@@ -1,19 +1,54 @@
# Let op: er staan hier GEEN cms-services meer.
#
# De applicatie wordt uitsluitend door scripts/ci-deploy.sh beheerd, dat een
# blue/green-release doet: de kandidaat start op de vrije poort, de live release
# blijft draaien en nginx wijst pas om als de kandidaat gezond is en de
# e2e-test heeft gewonnen. Een `cms`-service met `container_name: epicnext-cms`
# op poort 3002 was een achterhaalde replica uit een handmatige
# `docker compose up` en blokkeerde elke release op die poort — bovendien met
# een ander containernaam dan wat het deploy-script als slot A beheert
# (`epicnext-cms-app`), waardoor het script de bezette poort niet eens aan de
# juiste container kon toeschrijven.
#
# Wat je hier wilt starten hoort in een apart compose-bestand te staan, of
# expliciet via scripts/ci-deploy.sh te lopen.
# ─────────────────────────────────────────────────────────────────────────────
# Next.js CMS — blue/green
# ─────────────────────────────────────────────────────────────────────────────
x-cms: &cms
image: epicnext-cms:${CMS_RELEASE:-local}
build:
context: .
dockerfile: Dockerfile
args:
NEXT_DEPLOYMENT_ID: ${CMS_RELEASE:-unknown}
network: host
network_mode: host
stop_grace_period: 15s
restart: unless-stopped
env_file:
- .env
volumes:
- ./public/nitro-assets:/app/public/nitro-assets
- ./public/swf:/app/public/swf
- ./storage:/app/storage
- /var/www/Gamedata:/var/www/Gamedata
# ── Resource limits ──
mem_limit: 6g
memswap_limit: 7g
cpus: 2.0
pids_limit: 512
healthcheck:
test: ["CMD", "node", "-e", "fetch('http://127.0.0.1:'+(process.env.PORT||'3002')+'/api/health').then(r=>{process.exit(r.ok?0:1)}).catch(()=>process.exit(1))"]
interval: 15s
timeout: 5s
retries: 3
start_period: 40s
services:
cms:
<<: *cms
container_name: epicnext-cms
environment:
- HOSTNAME=0.0.0.0
- PORT=3002
cms-green:
<<: *cms
container_name: epicnext-cms-green
profiles: ["green"]
environment:
- HOSTNAME=0.0.0.0
- PORT=3003
byparr:
image: ghcr.io/thephaseless/byparr:latest
container_name: byparr