fix(auto-apply): block multi-module push batches #266

Merged

pdurlej merged 1 commit from codex/hardening/auto-apply-multi-module-guard into main

2026-05-13 19:03:07 +02:00

codex commented

2026-05-13 19:01:47 +02:00

Collaborator

Canary status: missing — control-plane workflow guard; run canary/CI before merge if branch protection does not already require it.

Canary Context Pack

Product story

Before F2, the auto-apply lane needs one more PM-safety brake: broad metadata batches should not get near a deploy-host plan/apply loop just because they touched modules/**.

What changed

auto_apply_scope.py now distinguishes source=push from manual dispatch and blocks automatic push-triggered auto-apply when more than one module changed.

Manual module classification remains possible via --module, preserving explicit operator/agent-triggered single-target smoke behavior.

Why it changed

PR #263 intentionally changed 49 module manifests. The workflow failed safely, but only after entering the deploy-host auto-apply job. This guard makes that case explicit and early: push auto-apply is single-module only.

Files touched

control-plane/platformctl/ci/auto_apply_scope.py
control-plane/platformctl/tests/test_forgejo_ci_scripts_contract.py

Relevant context

Issue #264
Issue #142 checkpoint after #263
Run/API #796: safe blocked failure after multi-module metadata batch
PR #261 watchdog proof: stuck job detection now works

Runtime evidence

No runtime mutation in this PR.

Local reproduction against the real #263 merge diff:

PYTHONPATH=control-plane python control-plane/platformctl/ci/auto_apply_scope.py \
  --base ebfd9f2fce7505184601092782ec46e84764b88d \
  --head b1c5333abbe6956cade4e1840685219246272bc9 \
  --fail-on-blocked

rc=4
source=push
status=blocked
safe_to_apply=false
blocker: push auto-apply accepts exactly one module; changed modules: ...

Known constraints

This still lets the workflow start, because Forgejo path filtering is coarse. The safety improvement is that the job fails at scope classification before platformctl plan/apply can loop over modules.

Explicit out-of-scope

No F2 dispatch
No F3 work
No production apply
No workflow trigger redesign

Requested decision

Merge as the last safety check before preparing F2.

Merge blockers

If reviewer wants multi-module push auto-apply to be supported in v1, this PR intentionally rejects that.
If manual workflow_dispatch should also be single-module-only, that should be a separate policy decision; current workflow UI only accepts one module string.

Verification

pytest control-plane/platformctl/tests/test_forgejo_ci_scripts_contract.py -q → 25 passed
pytest control-plane/platformctl/tests/test_forgejo_ci_scripts_contract.py control-plane/platformctl/tests/test_apply_phase3.py tests/test_deploy_runner_watchdog.py -q → 71 passed
Real #263 diff simulation → blocked with rc=4, before plan/apply

Spec sources read

control-plane/platformctl/ci/auto_apply_scope.py — implementation target
control-plane/platformctl/tests/test_forgejo_ci_scripts_contract.py — contract tests
.forgejo/workflows/platformctl-auto-apply.yml — caller behavior
Issue #264 — acceptance criteria

Closes #264.
Refs #142.

Canary status: missing — control-plane workflow guard; run canary/CI before merge if branch protection does not already require it. ## Canary Context Pack ### Product story Before F2, the auto-apply lane needs one more PM-safety brake: broad metadata batches should not get near a deploy-host plan/apply loop just because they touched `modules/**`. ### What changed `auto_apply_scope.py` now distinguishes `source=push` from manual dispatch and blocks automatic push-triggered auto-apply when more than one module changed. Manual module classification remains possible via `--module`, preserving explicit operator/agent-triggered single-target smoke behavior. ### Why it changed PR #263 intentionally changed 49 module manifests. The workflow failed safely, but only after entering the deploy-host auto-apply job. This guard makes that case explicit and early: push auto-apply is single-module only. ### Files touched - `control-plane/platformctl/ci/auto_apply_scope.py` - `control-plane/platformctl/tests/test_forgejo_ci_scripts_contract.py` ### Relevant context - Issue #264 - Issue #142 checkpoint after #263 - Run/API #796: safe blocked failure after multi-module metadata batch - PR #261 watchdog proof: stuck job detection now works ### Runtime evidence No runtime mutation in this PR. Local reproduction against the real #263 merge diff: ```text PYTHONPATH=control-plane python control-plane/platformctl/ci/auto_apply_scope.py \ --base ebfd9f2fce7505184601092782ec46e84764b88d \ --head b1c5333abbe6956cade4e1840685219246272bc9 \ --fail-on-blocked rc=4 source=push status=blocked safe_to_apply=false blocker: push auto-apply accepts exactly one module; changed modules: ... ``` ### Known constraints This still lets the workflow start, because Forgejo path filtering is coarse. The safety improvement is that the job fails at scope classification before `platformctl plan/apply` can loop over modules. ### Explicit out-of-scope - No F2 dispatch - No F3 work - No production apply - No workflow trigger redesign ### Requested decision Merge as the last safety check before preparing F2. ### Merge blockers - If reviewer wants multi-module push auto-apply to be supported in v1, this PR intentionally rejects that. - If manual `workflow_dispatch` should also be single-module-only, that should be a separate policy decision; current workflow UI only accepts one module string. ## Verification - `pytest control-plane/platformctl/tests/test_forgejo_ci_scripts_contract.py -q` → 25 passed - `pytest control-plane/platformctl/tests/test_forgejo_ci_scripts_contract.py control-plane/platformctl/tests/test_apply_phase3.py tests/test_deploy_runner_watchdog.py -q` → 71 passed - Real #263 diff simulation → blocked with `rc=4`, before plan/apply ## Spec sources read - `control-plane/platformctl/ci/auto_apply_scope.py` — implementation target - `control-plane/platformctl/tests/test_forgejo_ci_scripts_contract.py` — contract tests - `.forgejo/workflows/platformctl-auto-apply.yml` — caller behavior - Issue #264 — acceptance criteria Closes #264. Refs #142.

codex added 1 commit

2026-05-13 19:01:47 +02:00

fix(auto-apply): block multi-module push batches

canary-required / collect-diff (pull_request) Successful in 4s

Details

infra-docs-drift / docs-drift (pull_request) Successful in 5s

Details

python-ci / Python 3.11 (pull_request) Successful in 43s

Details

canary-required / canary (pull_request) Successful in 14s

Details

platformctl plan / auto-apply scope (pull_request) Successful in 23s