Pull the server image on the Pi instead of building it
The Pi now runs registry.mc02.dev/schulcloud-mcp. Its compose file `!reset`s the build section docker-compose.yml declares, so no `docker compose` command there can fall back to building (Compose 2.24 or later). SCHULCLOUD_MCP_TAG pins a commit's image; unset, the Pi follows `latest`. `npm run publish-image` publishes from a development machine. It builds only a clean working tree, so a commit tag names exactly that commit's code, for amd64 and arm64, tagged `latest` and with the short commit id. On an x86 machine arm64 builds under QEMU, which the script checks for and explains rather than registering unasked. PI.md logs in to the registry, pulls and starts instead of building, and updates by publishing and pulling. Rehearsed in a scratch compose project: the image came from the registry, `up -d --build` built nothing, and the server came up healthy with its database and no published ports. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -26,13 +26,17 @@ npm run probe # verify token + API assumptions against the LIVE instance
|
||||
npm run smoke # full end-to-end: real server + real MCP client + real data
|
||||
npm run keepalive-status # is the deployed container holding its session?
|
||||
npm run session-diagnose # ~2.5h: measure what actually ends the session
|
||||
npm run publish-image # amd64 + arm64 image to registry.mc02.dev; clean tree only
|
||||
```
|
||||
|
||||
`docker-compose.override.yml` is local-only and publishes the server on
|
||||
`127.0.0.1:8080` (or `MCP_HOST_PORT`) and Postgres on `127.0.0.1:55432`; see
|
||||
`docs/LOCAL.md`. Compose merges it whenever `COMPOSE_FILE` is unset, so the Pi's
|
||||
`.env` sets `COMPOSE_FILE=docker-compose.yml:deploy/docker-compose.pi.yml`
|
||||
instead; `docs/PI.md` is the setup guide. When `.env` points at the live account, test against the local
|
||||
instead; `docs/PI.md` is the setup guide. **The Pi never builds**: that file runs
|
||||
`registry.mc02.dev/schulcloud-mcp` and `!reset`s the build section, and
|
||||
`npm run publish-image` is how an image gets there — so a change reaches the
|
||||
Pi only once it is committed and published. When `.env` points at the live account, test against the local
|
||||
instance only through `local-instance/scripts/mcp-env.sh`: it pins its own
|
||||
database (`schulcloud_local`) and mirror, so fixtures cannot reach the live
|
||||
index.
|
||||
|
||||
Reference in New Issue
Block a user