You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(ci): compose release qualification from targets, flows, and suites #2972
Create a reusable release qualification entry point that consumes an immutable candidate artifact set and composes three independently maintained dimensions:
targets describe the platform, architecture, runtime, package mechanism, and environment lifecycle;
flows describe how a release is installed or changed, such as clean install or forward upgrade;
suites describe the behavior to verify, such as driver conformance.
The qualification matrix must select supported combinations explicitly rather than assume every target, flow, and suite forms a valid Cartesian product.
The first consumer will be the Fedora rootless Podman proof-of-concept covering clean installation and N to N+1 forward upgrade. Existing release canaries mix environment setup, installation, and assertions in individual workflow jobs, making each new matrix entry expensive to add and difficult to compare.
Definition of Done
Qualification accepts an immutable candidate artifact manifest containing the release version, source commit, and artifact identities or digests.
Targets, flows, and suites have separate definitions and lifecycle boundaries.
Adding a target does not require copying or modifying flow or suite implementations.
Adding a flow or suite does not require embedding target-specific provisioning logic.
Supported target, flow, and suite combinations are selected explicitly without generating an unsupported Cartesian product.
The same qualification entry point can run locally and from GitHub Actions.
Each selected combination produces a clear pass/fail result plus machine-readable results and retained diagnostics.
Documentation explains how to add one target, one flow, or one suite independently.
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
PR #3419 completes this issue under the revised tmachine composition model.
The original target / flow / suite design is superseded by three independent dimensions:
a scenario defines the machine and runtime setup;
an installation profile defines how OpenShell is installed;
a testsuite defines the behavior exercised after installation.
#3419 adds the missing installation boundary, allowing runtime scenarios to be reused across native and future package-based installations. A separate flow abstraction is no longer needed: clean installation is represented by an installation profile, while stateful operations such as installing N and upgrading to N+1 will be implemented as a testsuite.
Once #3419 merges, #2972 can be considered complete. The N-to-N+1 work remains tracked separately by #2975.
Activity
github-actions commentedon Sep 10, 2026
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
SDAChess commentedon Sep 17, 2026
PR #3419 completes this issue under the revised tmachine composition model.
The original target / flow / suite design is superseded by three independent dimensions:
#3419 adds the missing installation boundary, allowing runtime scenarios to be reused across native and future package-based installations. A separate flow abstraction is no longer needed: clean installation is represented by an installation profile, while stateful operations such as installing N and upgrading to N+1 will be implemented as a testsuite.
Once #3419 merges, #2972 can be considered complete. The N-to-N+1 work remains tracked separately by #2975.