fix(auto-apply): block multi-module metadata batch pushes before deploy-host #264

New issue

Closed

opened 2026-05-13 18:40:17 +02:00 by codex · 0 comments

codex commented

2026-05-13 18:40:17 +02:00

Collaborator

Context

After PR #263 merged, platformctl-auto-apply.yml ran on push because the PR touched many modules/** files. Run/API #796 did fail safely: auto-apply-scope emitted status=blocked, safe_to_apply=false, and no platformctl plan/apply step ran.

Still, this is too noisy and too close to the deploy path for metadata-only batch PRs. Auto-apply should fail earlier and more explicitly for multi-module batch pushes, especially when stateful modules are included.

Evidence

Run/API: #796 / Forgejo UI run #660
Trigger: push to main at b1c5333abbe6956cade4e1840685219246272bc9 from PR #263
Watchdog behavior: PR #261 worked; it detected the stuck trusted-main auto-apply job and restarted forgejo-deploy-runner.service at 18:38 CEST.
Scope artifact: status=blocked, safe_to_apply=false; no apply artifact was produced.

Desired behavior

Auto-apply should not enter deploy-host execution for broad metadata batches. Recommended guard:

If event is push and changed module count > 1, classify as blocked before deploy-host plan/apply.
Optionally allow multi-module only for an explicit workflow_dispatch dry-run mode, not automatic main push.
Add tests for PR #263-like diffs: many modules/*/module.yaml metadata-only changes should produce a non-mutating blocked status with a clear message.

Scope

control-plane/platformctl/ci/auto_apply_scope.py
.forgejo/workflows/platformctl-auto-apply.yml only if needed for clearer early exit/evidence
tests for multi-module batch guard

Acceptance criteria

Multi-module push to main is blocked with a clear reason before any platformctl plan/apply loop.
Single-module stateless/main-push no-op smokes continue to work.
No production mutation.

Refs #142, #263, run #796.

## Context After PR #263 merged, `platformctl-auto-apply.yml` ran on `push` because the PR touched many `modules/**` files. Run/API #796 did fail safely: `auto-apply-scope` emitted `status=blocked`, `safe_to_apply=false`, and no `platformctl plan/apply` step ran. Still, this is too noisy and too close to the deploy path for metadata-only batch PRs. Auto-apply should fail earlier and more explicitly for multi-module batch pushes, especially when stateful modules are included. ## Evidence - Run/API: #796 / Forgejo UI run #660 - Trigger: push to `main` at `b1c5333abbe6956cade4e1840685219246272bc9` from PR #263 - Watchdog behavior: PR #261 worked; it detected the stuck trusted-main auto-apply job and restarted `forgejo-deploy-runner.service` at 18:38 CEST. - Scope artifact: `status=blocked`, `safe_to_apply=false`; no apply artifact was produced. ## Desired behavior Auto-apply should not enter deploy-host execution for broad metadata batches. Recommended guard: - If event is `push` and changed module count > 1, classify as blocked before deploy-host plan/apply. - Optionally allow multi-module only for an explicit workflow_dispatch dry-run mode, not automatic main push. - Add tests for PR #263-like diffs: many `modules/*/module.yaml` metadata-only changes should produce a non-mutating blocked status with a clear message. ## Scope - `control-plane/platformctl/ci/auto_apply_scope.py` - `.forgejo/workflows/platformctl-auto-apply.yml` only if needed for clearer early exit/evidence - tests for multi-module batch guard ## Acceptance criteria - Multi-module push to `main` is blocked with a clear reason before any `platformctl plan/apply` loop. - Single-module stateless/main-push no-op smokes continue to work. - No production mutation. Refs #142, #263, run #796.

codex added the

phase/03

risk/process

labels

2026-05-13 18:40:27 +02:00

codex referenced this issue

2026-05-13 18:41:35 +02:00

[coordination-lane] Cutover Flight Phase 2: v2 catalog to gate #142

codex referenced this issue from a pull request that will close it,

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

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

codex referenced this issue