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.
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
stablekernelorg, one per trunk model:environments: [], single trunk, release-only lifecycleCoverage
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:
cascade-rollbackworkflow, re-deploying a prior version resolved from the per-environment history ring (git-history fallback / explicit--to)allow_downgradeis set; the prod/terminal env always requires it)Scope notes
cli_version.Impact
This is the credibility gate: it proves the framework works on real GitHub for every supported topology, not just under local emulation.