Skip to content

test: real-GitHub validation across trunk models #27

@joshua-temple

Description

@joshua-temple

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions