openhands
c8b3054527
Gitea Actions Runner Test / test-job (push) Successful in 2s
CI / check (push) Successful in 33s
CI / tests-integration (push) Successful in 1m46s
CI / tests-unit (push) Failing after 1m49s
CI / tests-ui (push) Successful in 2m39s
CI / preflight (push) Skipped
CI / deploy (push) Skipped
The deploy could not start its candidate because port 3002 was held by `epicnext-cms`, a `docker compose up` replica built from the `local` image and serving no traffic. Everything else in the pipeline was healthy: the image built, the news browser gate passed and migrations were current. The container was unusable for this pipeline for two reasons. It ran a different image than any release, and its name did not match the slot the deploy script manages — docker-compose.yml pinned `container_name: epicnext-cms` while ci-deploy.sh expects `epicnext-cms-app` for slot A. Slot B happened to agree (`epicnext-cms-green`), which is why 3003 deployed fine and 3002 never could. deploy.sh already documents that compose "never managed the release that actually ran", so the service was stale by its own account. Removed the stray container and dropped the `cms` and `cms-green` services (plus the now-unused x-cms anchor) from docker-compose.yml, so a reboot cannot resurrect a replica that permanently occupies a blue/green slot. byparr is untouched. Also fixed the diagnostic from the previous commit, which blamed every running container. `docker ps --filter publish=` returns nothing for --net=host containers, so the fallback listed all of them and buried the real holder among seven innocent ones. It now resolves the listening PID from `ss` back to its container through /proc/<pid>/cgroup and names only that one, with the exact `docker rm -f` command to run. Verified: port 3002 free, live release on 3003 still serving (status ok, database and redis true), deploy simulation 26 passed, typecheck.
30 lines
1.1 KiB
YAML
30 lines
1.1 KiB
YAML
# 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.
|
|
|
|
services:
|
|
byparr:
|
|
image: ghcr.io/thephaseless/byparr:latest
|
|
container_name: byparr
|
|
network_mode: host
|
|
restart: unless-stopped
|
|
environment:
|
|
- LOG_LEVEL=INFO
|
|
pids_limit: 256
|
|
healthcheck:
|
|
test: ["CMD", "curl", "http://localhost:8191/health"]
|
|
interval: 30s
|
|
timeout: 10s
|
|
retries: 3
|
|
start_period: 30s |