Files

T

fisher 62c62baf05 Share the target filter, fix cd-status branch, record deploy status

- enabled_targets/names_for: one implementation of 'a host acts only on its
  own targets'; --host s5 and --host s5.fisher.hu now select the same targets
- shell_value: JSON booleans reach shell consumers as true/false
- cd-status: capture before eval, so the unconfigured-host branch is reachable
- cd-deploy writes a .status record; cd-status reads it instead of grepping
  the log's prose
- cd-render-hooks --list-urls replaces two inline JSON readers

2026-08-23 08:50:45 +00:00

2.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.

2.0 KiB Raw Blame History

Hints

2.0 KiB

Raw Blame History