Files
my-cd-webhook/docs/hints.md
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

40 lines
2.0 KiB
Markdown

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