Routine-looking promotion pull requests can currently trigger an application’s first production deployment without telling the reviewer. A decider may approve what appears to be digest bookkeeping while it actually creates migration and service units, mutates a fresh database, exposes a new public endpoint, and starts the production container.
The canonical image-promotion writer uses the same provenance-focused opening for both ordinary digest updates and disabled-to-pinned first promotions. Personal-infra PR #100 demonstrated the gap: its body said only that the image was proven, while merging would have deployed CG-BiBi for the first time at neu.cg-bibi.de. This violates the consumer repositories’ requirement that PR descriptions lead with product behavior and operational stakes.
Update the canonical promotion PR generator so it detects a disabled/null-pins to enabled/pinned transition and opens with explicit first-deployment effects: migration runs, service starts, public endpoint becomes active, and declared registry prerequisites are required. Ordinary later promotions should retain concise update wording. Ratchet both shapes with executable generator/workflow tests.
Suggested verification: generate one PR body from an adopted disabled entry and one from an already-live entry; assert only the first names first deployment and its effects. Sync the canonical change to consumers through the standards workflow.
Found during review-fix of https://github.com/davidvornholt/personal-infra/pull/100. This is deferred from that bot PR because trusted promotion branches must remain infra/images.json-only.
Routine-looking promotion pull requests can currently trigger an application’s first production deployment without telling the reviewer. A decider may approve what appears to be digest bookkeeping while it actually creates migration and service units, mutates a fresh database, exposes a new public endpoint, and starts the production container.
The canonical image-promotion writer uses the same provenance-focused opening for both ordinary digest updates and disabled-to-pinned first promotions. Personal-infra PR #100 demonstrated the gap: its body said only that the image was proven, while merging would have deployed CG-BiBi for the first time at
neu.cg-bibi.de. This violates the consumer repositories’ requirement that PR descriptions lead with product behavior and operational stakes.Update the canonical promotion PR generator so it detects a disabled/null-pins to enabled/pinned transition and opens with explicit first-deployment effects: migration runs, service starts, public endpoint becomes active, and declared registry prerequisites are required. Ordinary later promotions should retain concise update wording. Ratchet both shapes with executable generator/workflow tests.
Suggested verification: generate one PR body from an adopted disabled entry and one from an already-live entry; assert only the first names first deployment and its effects. Sync the canonical change to consumers through the standards workflow.
Found during review-fix of https://github.com/davidvornholt/personal-infra/pull/100. This is deferred from that bot PR because trusted promotion branches must remain
infra/images.json-only.