CANP-WP-0006 T06: container image and smoke checks

Two-stage python:3.12-slim build with no toolchain in the runtime layer,
running non-root (uid 10001) and writing nothing to disk — its state is the
database. reference/ is a real build input, because the service delegates
validation to it so the two cannot disagree about what a valid package is.

Migrations deliberately do not run at start-up. A schema change is a deployment
step with its own rollback, not something that races between replicas.

tools/smoke.py asserts what can be known about a running service: liveness,
readiness, fleet health shape, migration revision, and that the index and
registry are queryable. stdlib only, so it runs inside the runtime image;
non-zero exit, so a deployment gate can call it directly.

Verified by running it, not by inspection: the container starts, all six checks
pass against it, the reference CLI installs a package from it over HTTP, and
the checks fail correctly against a wrong --expect-migration — so
migration-at-head is a real check rather than a decorative one. Without
--expect-migration the check can only confirm the schema is stamped at all, and
says so rather than implying it verified the head.

Cluster-level checks a rapp contract also names — NetworkPolicies present,
external secrets ready, private-Service-only, live image digest match — are
properties of the deployment and belong to rapp-canned-prompts.

The digest rapp.yaml would pin does not exist yet. The image was built locally
and verified, but never pushed; that digest exists only once the image is
published to the fleet registry, which needs credentials and is outward-facing
enough not to do unasked. The follow-on sequence for rapp-canned-prompts is
recorded in the workplan.

CANP-WP-0006 is finished. Service tests 33, reference 105.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bjefh8NUiEiahN4JLwoSKM

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 388925@bnt-lap001
Assistant-Session: 3507023f-e0fd-4a1e-9d90-a0d4217d1502
This commit is contained in:
tegwick 2026-09-06 21:25:48 +02:00
parent 39b499bcec
commit f41d1b705f
6 changed files with 260 additions and 10 deletions

View file

@ -4,7 +4,7 @@ type: workplan
title: "Hosted registry and index service"
domain: agents
repo: canned-prompts
status: active
status: finished
owner: codex
topic_slug: practice
created: "2026-09-06"
@ -245,7 +245,7 @@ its only dependency. Registry responses are treated as untrusted input (§ 19):
```task
id: CANP-WP-0006-T06
status: todo
status: done
priority: medium
state_hub_task_id: "3c008ebe-bf07-5cee-8678-7b1ed27283ef"
```
@ -253,5 +253,42 @@ state_hub_task_id: "3c008ebe-bf07-5cee-8678-7b1ed27283ef"
Dockerfile and a published image, plus the checks a `rapp` smoke contract will
assert: health ok, migration at head, private service only, image digest match.
Completing this produces the digest that `rapp-canned-prompts` needs to pin, at
which point that repo can be created against something real.
**Done, with one honest limit.**
The image builds and was verified by running it: a two-stage `python:3.12-slim`
build with no toolchain in the runtime layer, non-root (uid 10001), writing
nothing to disk. All six smoke checks passed against the running container, and
the reference CLI installed a package from it over HTTP.
Migrations deliberately do **not** run at start-up. A schema change is a
deployment step with its own rollback, not something that races between
replicas.
`tools/smoke.py` covers what can be known about a *running service* — liveness,
readiness, fleet health shape, migration revision, index and registry
queryable. stdlib only, so it runs inside the runtime image; non-zero exit, so
a deployment gate can call it. Verified in both directions: it passes against
the container and fails against a wrong `--expect-migration`, so
`migration-at-head` is a real check rather than a decorative one.
Cluster-level checks a rapp contract also names — NetworkPolicies present,
external secrets ready, private-Service-only, live image digest match — are
properties of the deployment and belong to `rapp-canned-prompts`.
**The digest does not exist yet.** The image was built locally
(`sha256:4878b208…`, 76 MB) but never pushed. `rapp.yaml` pins
`upstream_components.version` to a digest from the fleet's registry, which
exists only once the image is published — an operator action needing registry
credentials, and outward-facing enough that it is not mine to take unasked.
## Follow-on: rapp-canned-prompts
Not a task in this workplan; recorded so the sequence is not lost.
1. Publish the image to the fleet registry and capture its digest.
2. Create `rapp-canned-prompts` with `ownership_repo: canned-prompts`,
`readiness_state: draft`, and that digest in `upstream_components`.
3. Add the deployment-level smoke checks, calling `tools/smoke.py` for the
service-level half.
4. Decide the PostgreSQL binding with `rapp-postgres` and the credential
broker, per the shape `rapp-sbom-nexus` uses.