test: real-GitHub validation across trunk models #27

Goal

Validate orchestrate + promote on real GitHub (not just the local act-based harness) across every trunk model the generator supports. The local e2e suite proves generator output and runs workflows under act; this issue proves the framework end-to-end against the real GitHub Actions runtime, environment gates, and API surface.

Approach

Stand up example test repos under the stablekernel org, one per trunk model:

• no-env - environments: [], single trunk, release-only lifecycle
• 2-env - minimal promotion chain
• 3-env - intermediate cascade
• 4-env cascade - full dev -> test -> uat -> prod promotion cascade

Coverage

Validate the real-GitHub behavior below, in the trunk models where each path is meaningful. Not every path applies to every model (a no-env repo has no promotion or rollback), so coverage is allocated rather than run blanket in every repo:

• Orchestrate on merge to trunk (all models): change detection, build/deploy callback dispatch, state write-back
• Dry-run codepaths (all models): emulated outputs without skipping
• Failure handling and idempotency (all models): re-running a dispatch is safe
• Release lifecycle (no-env, plus the terminal stage of the multi-env models): tag + changelog + GitHub release
• Promotion between environments (2-env, 3-env, 4-env): SHA-pinned promotion, breaking-change gate, state propagation
• Hotfix / re-promote flows (one multi-env model, e.g. the 4-env cascade)
• Rollback flows (validate in the 2-env model for the core paths, and the 4-env cascade for the full divergence/rejoin behavior across a chain; not in every repo):
  • Auto-rollback on a failed deploy (the env reverts to its prior SHA), for both promote and hotfix
  • Manual arbitrary-depth rollback via the generated cascade-rollback workflow, re-deploying a prior version resolved from the per-environment history ring (git-history fallback / explicit --to)
  • The downgrade gate (promoting an older version onto an env is blocked unless allow_downgrade is set; the prod/terminal env always requires it)
  • Divergence + rejoin (a rolled-back env is marked diverged so an onward promote of the downgrade is guarded, and a roll-forward rejoins and clears it)

Scope notes

• These repos double as living examples for adopters; keep their manifests clean and minimal.
• Each repo wires the published composite actions and pins a cli_version.
• The local act+gitea harness already covers rollback (five scenarios: re-deploy prior, deployable-scoped, marks-diverged-blocks-promote, failed-deploy-leaves-state, roll-forward rejoins). The real-GitHub validation re-proves the allocated subset above against the live runtime.
• Capture any divergence from the local act harness as follow-up issues.

Impact

This is the credibility gate: it proves the framework works on real GitHub for every supported topology, not just under local emulation.