Problem — we don't dogfood CD
Validation CI is dogfooded: ubuntu/windows/macos-latest are generated from build/Build.CI.GitHubActions.cs and just call dotnet fallout Test Pack. Delivery is not:
experimental.yml / preview.yml / release.yml are hand-written YAML inlining dotnet nuget push --source … --api-key … --skip-duplicate.- We have an
IPublish.Publish target, but it models a single NuGetSource + single key. It can't express: GitHub Packages (all pkgs) vs nuget.org (Fallout.* only, opt-in) vs GitHub Releases; per-lane routing (alpha/preview/GA); the approval gate.
- The
[GitHubActions] generator models "run these targets", not deployment pipelines (multi-env fan-out, dispatch flags, conditional jobs) — so publish workflows are hand-authored.
The gap is fillable in the framework. The only irreducible external piece is the human approval gate, which becomes a pluggable provider.
Goal — manage CD as code
A richer Publish/Deploy surface consumes these so the CI YAML becomes a thin generated shell calling dotnet fallout Deploy — same as validation calls dotnet fallout Test.
Config model — injected or standalone
Definitions resolve through configuration providers:
- Injected from a parent system — GitHub (Environments/secrets), Octopus, Azure DevOps.
- Standalone — wire up an
appsettings.json and Fallout drives it all itself.
This lets the same build run inside a forge or fully self-hosted, and absorbs the approval gate (delegate to GitHub/Octopus, or a Fallout server when standalone).
Why it matters
A major step toward Fallout as a standalone, self-hostable CI/CD product — the thing that owns channels, environments, and promotions end-to-end, not just a build tool someone else's pipeline invokes.
Child issues
Umbrella: #106. Relates to #113, #249, #252, #285, #286.
Problem — we don't dogfood CD
Validation CI is dogfooded:
ubuntu/windows/macos-latestare generated frombuild/Build.CI.GitHubActions.csand just calldotnet fallout Test Pack. Delivery is not:experimental.yml/preview.yml/release.ymlare hand-written YAML inliningdotnet nuget push --source … --api-key … --skip-duplicate.IPublish.Publishtarget, but it models a singleNuGetSource+ single key. It can't express: GitHub Packages (all pkgs) vs nuget.org (Fallout.*only, opt-in) vs GitHub Releases; per-lane routing (alpha/preview/GA); the approval gate.[GitHubActions]generator models "run these targets", not deployment pipelines (multi-env fan-out, dispatch flags, conditional jobs) — so publish workflows are hand-authored.The gap is fillable in the framework. The only irreducible external piece is the human approval gate, which becomes a pluggable provider.
Goal — manage CD as code
alpha/preview/rc/stable) — versioning + feed routing + maturity rules.nuke :setup— mirrors upstream #1588 #14–Azure DevOps: incorrect GitRepository branch value with multi-repo pipelines — mirrors upstream #1587 #17), SSH host (Fallout.Ssh — managed SSH/SFTP wrapper with ssh-config integration and typed PosixMode #250)…dev→staging→prod), with promotion + approval.A richer
Publish/Deploysurface consumes these so the CI YAML becomes a thin generated shell callingdotnet fallout Deploy— same as validation callsdotnet fallout Test.Config model — injected or standalone
Definitions resolve through configuration providers:
appsettings.jsonand Fallout drives it all itself.This lets the same build run inside a forge or fully self-hosted, and absorbs the approval gate (delegate to GitHub/Octopus, or a Fallout server when standalone).
Why it matters
A major step toward Fallout as a standalone, self-hostable CI/CD product — the thing that owns channels, environments, and promotions end-to-end, not just a build tool someone else's pipeline invokes.
Child issues
IPublish: multi-channel, package-ID-aware publishingReleaseChannel/DeploymentTarget/Environmentmodelappsettings.json+ GitHub/Octopus injectors)[GitHubActions]generator: emit CD pipelines / delegate todotnet fallout DeployUmbrella: #106. Relates to #113, #249, #252, #285, #286.