Fallout-build / Fallout-build/Fallout

[Epic] Code-managed release channels, deployment targets & environments (config-injectable, standalone-capable)

Open
#332 0 comments 0 reactions 0 assignees View on GitHub
enhancement RFC target/vNext
Dominant language
C#
Stars
154
Forks
19
Avg merge
1d 22h
Merged PRs (30d)
15

Description

## 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
- **Release channels** (`alpha`/`preview`/`rc`/`stable`) — versioning + feed routing + maturity rules.
- **Deployment targets** — NuGet feed, GitHub Release, container registry, cloud target (#14–#17), SSH host (#250)…
- **Environments** — named, ordered, gated (`dev` → `staging` → `prod`), with promotion + approval.

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
- [ ] #333 — `IPublish`: multi-channel, package-ID-aware publishing
- [ ] #334 — first-class `ReleaseChannel` / `DeploymentTarget` / `Environment` model
- [ ] #335 — configuration-provider abstraction (standalone `appsettings.json` + GitHub/Octopus injectors)
- [ ] #336 — `[GitHubActions]` generator: emit CD pipelines / delegate to `dotnet fallout Deploy`
- [ ] #337 — approval-gate provider abstraction (platform-delegated or Fallout-server)

---
Umbrella: #106. Relates to #113, #249, #252, #285, #286.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.