Reverses the placement decision made an hour ago. That one put the APK only on
the data volume, reasoning that ~55 MiB should not be charged to installs that
never touch Android. The operator's call is that ending the manual copy is worth
the megabytes, and it is their deployment.
CI now fetches the newest published client into the build context immediately
before the image build, so `:dev`, `:latest` and `:<version>` all ship one and a
`docker compose pull` delivers a new server and a new client together.
**Always the rolling `dev` release — the newest build there is.** A versioned
image therefore carries the newest client rather than one pinned to that
version. Deliberate: the two negotiate a sync protocol version before linking, so
a mismatch is caught by the handshake, and pinning would buy nothing the
handshake does not already provide.
**Fetched by the JOB, never by the Dockerfile.** The release is private, and a
token used inside a build ends up in the context or a layer.
**It cannot fail the image build.** No release yet, a network blip, a first-ever
build — all of them log a warning and produce an image with no client, which is a
state the server already supports. Half a pair is cleaned up rather than shipped:
a sidecar without its APK is worse than neither, because the server would be
describing something it cannot serve.
**The volume still wins.** `DATA_DIR/client/` is checked first and the baked copy
second, so an operator who deliberately drops a build in gets that build — and a
BROKEN drop-in falls through to the image's copy rather than taking the feature
offline, which is what makes the copy-order advice survivable instead of
load-bearing. Three tests cover the precedence, including that last case.
The baked copy lives inside the package, not under DATA_DIR: that path is a
volume mount, and anything the image wrote there would disappear behind it the
moment one is attached.
`client/.keep` is tracked so `COPY client/` cannot fail on a tree where the CI
step never ran; the artifacts themselves are gitignored, since a 55 MiB binary
does not belong in git history and is re-fetched on every build anyway.
New thoughtsync.dbwait polls the DB (SELECT 1) up to 60×1s before startup,
logging each attempt, so a briefly slow/unready database no longer crash-
loops the container. Wired as `python -m thoughtsync.dbwait &&` ahead of
`alembic upgrade head` in the image CMD and the dev compose command; exits
non-zero after the window so a restart policy can take over. Prod compose
gains restart: unless-stopped as the complementary piece.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm
- 2-stage Dockerfile (node:22 build Vue -> python:3.12-slim runtime); CMD runs
`alembic upgrade head` then hypercorn (rule 82).
- .forgejo/workflows/ci.yml on ci-python:3.14: typecheck (vue-tsc) + lint
(ruff check src/) + test (uv venv + pytest, DB-free) + gated buildx push with
the rule-46 tag scheme (:dev/:latest/:<sha>). No local integration lane yet.
- ci-requirements.md (rule 39); docker-compose for a local app+Postgres stack.
- Real README with layout, dev instructions, and the milestone arc.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm
bvandeusen
