[codecollision]

Two changes requested by the flowcanon agent after flowcanon.com's 2.2.3 deploy failed (gh run 39691894723).

Start a rolling service that has nothing to roll from

2.2.3 added a scheduler with no deploy.strategy. A rolling deploy scales to 2, which assumes an old container already exists. With none, it started two new containers, failed with "Could not identify old/new containers" and reverted the whole deploy. A rolling service with no running container (new, or stopped) is now pulled, started at 1 and health-checked, as drain-first services already were. If it fails, it is removed and the deploy reverts as usual.

deploy.post-deploy hooks

web:
  labels:
    deploy.role: app
    deploy.post-deploy: python manage.py setup_pages

• Runs once per hooked service it deployed, via compose exec -T <svc> sh -c '<cmd>', in deploy.order, after every service is healthy.
• Output goes into the deploy log.
• A failing or interrupted hook warns (with a GitHub annotation) and the deploy still exits 0.
• A failed deploy runs no hooks. --service runs only the hooks of the services it deploys.
• The label's $$ is unescaped to $. compose config prints a literal $ as $$, which real Docker exposed: without the unescape, $$VAR ran as the shell's PID followed by VAR.

Tests

• 350 unit tests pass, with 100% coverage. New: tests/test_new_service.py and tests/test_post_deploy.py. FakeHost now models compose recreating stopped diverged containers too.
• The full integration suite (36 tests) passes against real Docker (Compose v5.0.2). It adds three tests: a new rolling service, a stopped rolling service, and a hook running in the v2 container after a cutover.

Not changed: reverting services that already shipped

In 2.2.3 the backend was rolled back onto a schema that had already been migrated, and it never came healthy. That is the documented expand-then-contract contract, so this PR keeps the revert as it is. With the new-service fix, that deploy wouldn't have failed at all.

🤖 Generated with Claude Code