Both image workflows now emit a <timestamp>-<sha> tag on main pushes
alongside the existing sha-<short>/latest tags. Flux's ImagePolicy needs a
sortable tag to pick the newest build; latest is mutable and sha-<short>
has no ordering, so neither could drive auto-deploy. Same scheme as the
Talos devbox image.
Tag is stamped at build time (UTC); re-running a stale build would sort
newest, so prefer reverting over re-running. api and control build via
separate workflows/policies and can skew if one fails.
Add a second image for the handler control CLI (spawn/list/kill, approve/
reject, forge-init, CI poller) alongside the existing API image. It shares
the package, database, and /var/lib/handler volume but runs the control
process instead of uvicorn.
- Dockerfile.control: git + tmux baked in for live spawning; default CMD is
the `poll-ci --watch` loop; RUN_MIGRATIONS toggle reuses docker-entrypoint.sh.
- docker-control.yml: builds/pushes ghcr.io/<repo>/control (multi-arch),
scoped gha cache so it doesn't clobber the API build.
- docker-compose.yml: new `control` service, RUN_MIGRATIONS=false, depends on
the API (which owns migrations) being healthy.
- README: Containers section documenting both images and compose usage.
0xWheatyz
Claude