Files

T

fisher 952de1ea8e Fix health endpoint, align with the documented manual runbook

The health router is mounted at prefix="/api" in domaindingo's main.py, so
/health 404s. Checking it would have failed every deploy and rolled back a
perfectly good image.

Also adopts three conventions from the vault's DomainDingo Development note:
recreate a single named service (--no-deps --force-recreate), validate with
compose config --quiet before touching the running container, and write the
rollback record in the documented format and location.

2026-08-23 08:53:26 +00:00

3.0 KiB

Raw Blame History

Hints

Short notes on things that were not obvious. Prune stale ones.

bin/cd-target cannot be imported normally. The hyphen in the filename is not a valid Python identifier, so bin/cd-render-hooks loads it through importlib.machinery.SourceFileLoader. Importing importlib.util alone is not enough — importlib.machinery needs its own import.
if eval "$(cmd)" tests the wrong thing. eval reports the status of the string it evaluates, and an empty string is success — so a failing cmd makes the if take the true branch with nothing assigned, and set -u then aborts on the first variable the branch reads. Capture first (if out="$(cmd)"; then eval "$out"). This had made cd-status's "host is not configured" message unreachable.
docker/metadata-action's type=sha,format=short produces 7 characters. That is why image_tag_template uses {short7}. domaindingo's build.yml prefixes it with the branch, giving test-sha-abc1234 / prod-sha-abc1234.
domaindingo's compose stacks are not in the domaindingo repo. Test and prod both live in sysadmin/uas-ng at docker/domaindingo/s5.fisher.hu/ (docker-compose.yml and docker-compose-prod.yml). The scripts/deploy-*.sh files still in the application repo point at compose files that do not exist on s5 — they are dead code for both environments that matter.
domaindingo test and prod both run on s5, not s2. Only dev is still on s2. The hostname != s2 guard in the old scripts therefore matched nothing and exit 0d, which reads as success.
Registry tags in this fleet have drifted before. domaindingo:0.1.149 once resolved to a different image than the one running, with a broken /login. This is why cd-deploy checks org.opencontainers.image.revision and deploys by digest.
docker compose down -v destroys the data volumes for these stacks. The retired paradicsomleves test script used it. cd-deploy only ever runs up -d.
domaindingo's health endpoint is /api/health, not /health. The route is declared as /health in src/domaindingo/api/status.py, but main.py mounts the router with prefix="/api". Checking /health gets a 404, which reads as a failed deploy and triggers a rollback. The vault's "DomainDingo Development" note is the authority here.
The manual runbook recreates one service, not the project. docker compose up -d --pull always --no-deps --force-recreate <service>. cd-deploy matches it (minus --pull always, since it has already pulled a pinned digest), so an automated deploy and a hand-run one converge on the same state.
Rollback records are a documented convention. <service>-rollback-<UTC timestamp>.env in backup-test/backup-prod, holding DD_ROLLBACK_IMAGE, DD_ROLLBACK_REVISION, DD_ROLLBACK_CAPTURED_AT. cd-deploy writes the same format in the same place, so an operator following the manual note can recover from an automated deploy.

3.0 KiB Raw Blame History

Hints

3.0 KiB

Raw Blame History