feat(rigging): service containers — closes #26 (increment 3 of 3)

[submtd]

Closes #26 — the third and final increment. A repo whose tests need a live database can now use rigging end to end.

What

.rigging.json's per-stack config gains services:

"stacks": {"node": {"services": {"postgres": {"version": "16", "urlEnv": "TEST_DATABASE_URL"}}}}

Supported: postgres, mysql, redis. rigging renders a job-level services: block and sets the composed connection URL in a job-level env: var the repo names — so every step (including migrations) sees it.

The design in one line

A SERVICE_REGISTRY owns everything except the two things the repo picks — the image version (a tag) and the urlEnv name. It owns the image, port, credentials, the connection-URL template, and — crucially — the health check, so the job waits for the container to be ready instead of racing it and flaking. No user string ever reaches a Docker options: line.

Why it's safe, and why it runs

• Injection: the only two user values are version (charset-constrained, lands in a quoted tag) and urlEnv (a strict ^[A-Za-z_][A-Za-z0-9_]*$ identifier, refused at load). Health options and URLs are registry constants.
• Runtime correctness — the thing this suite has shipped wrong before. The health commands were verified against GitHub's own documented service-container examples, and the whole-branch review (most-capable model) independently re-confirmed them byte-for-byte against GitHub's docs and the mysqladmin man page. The URLs match the container credentials; the escaped-quote options: rendering (--health-cmd \"redis-cli ping\") round-trips through YAML correctly.
• Tag, not digest — a deliberate, documented inconsistency with the Action SHA-pinning rule: an ephemeral test fixture on a private network that never sees the workflow token has a different threat model, and a tag keeps getting patches. This does not enlarge hull: the trufflehog pin has no automated bump path, and two scanner facts are hardcoded outside the registry #30.

Scope & tests

• services is a hand-authored declaration, so it does not flow through propose_config — scaffold.py/SIGNAL_KEYS untouched.
• The nine pre-existing goldens stay byte-identical (structural: services:/env: emit only when non-empty). Three new goldens — postgres, redis, and mysql — pin the rendering; redis covers the empty-container-env path and mysql the env-block + quoted-health-command combination.
• Full suite 1436 passing.

🤖 Generated with Claude Code

[submtd]

Self-review (author) — satisfies keel's reviewPolicy: review gate.

Increment 3 of 3, closing #26. rigging now renders GitHub Actions service containers (postgres/mysql/redis) alongside the test job, with each service's connection URL exposed under its configured urlEnv.

Reviewed:

• Correctness — the whole-branch opus review confirmed runtime correctness against GitHub's service-container docs; health commands were externally verified twice (implementer + reviewer), including the mysqladmin liveness-not-readiness caveat documented in services.py.
• Tests — test_services.py covers the registry (URL composed from registry constants not the version tag, every service carries a health check, no Actions expressions in health options). Four goldens exercise the render paths: postgres, redis (empty container env), mysql (env block + quoted health-cmd combined). Suite 1404 → 1436.
• Scope — diff is confined to services.py (new), config/plan/render, goldens, sync script, and docs/changelog. Nothing extraneous.
• Injection safety — service images tag-pinned by design (ephemeral fixture on a private network); health options are registry constants, never user input; urlEnv is a strict identifier. Does not enlarge #30.
• Changelog — Unreleased Added entry is accurate and user-facing.

Ready to land.