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

- **`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 0`d, 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`.