Per Chris's channel taxonomy (RFC #267 comment), this is Tier 3 — more bleeding-edge than GitHub Packages. Goal: let us and contributors verify a Fallout.* change works in a real consumer project before it merges, without polluting GitHub Packages with abandoned PR builds.
Concept
A Docker-based NuGet server runs locally (or in CI ephemeral containers) and accepts pushes of PR-scoped Fallout.* builds. A consumer project (tests/Consumers/Fallout.Consumer.Local/ — already exists as a sentinel) restores from it and exercises the new bits in a real consumer shape, end-to-end, without publishing externally.
Once it works locally, it becomes a CI step on PRs targeting main or release/vN. The check: "we can build, publish, restore, and consume Fallout.X.M.P-pr.NNN.SHA from a clean container."
Candidates
- BaGet — open-source .NET NuGet server, official Docker image. Most common self-hosted pick. Lightweight.
- NuGet.Server — Microsoft's reference impl, ASP.NET-based, less actively maintained.
- Sleet — static-file feed (no server process; serve from any HTTP server or S3/Azure Blob). Simpler ops, unusual shape.
- ProGet Free — commercial-ish free tier; UI-heavy.
Recommendation pending evaluation: BaGet. Active, official Docker image, simplest path to "stand it up in CI for 5 minutes per PR."
Acceptance criteria
Future direction (deferred)
Likely the seed for a devcontainer / Codespaces approach — contributors clone, open in devcontainer, and the local NuGet server is preconfigured with the rest of the dev env (.NET SDK via global.json, Fallout.Cli via .config/dotnet-tools.json). File the devcontainer follow-up once this base lands.
Out of scope
- Devcontainer setup (separate follow-up).
- Replacing GitHub Packages — Tier 3 is additive, not a replacement for Tier 2.
- Publishing to a public Docker registry — image is for local/CI use only.
Per Chris's channel taxonomy (RFC #267 comment), this is Tier 3 — more bleeding-edge than GitHub Packages. Goal: let us and contributors verify a
Fallout.*change works in a real consumer project before it merges, without polluting GitHub Packages with abandoned PR builds.Concept
A Docker-based NuGet server runs locally (or in CI ephemeral containers) and accepts pushes of PR-scoped
Fallout.*builds. A consumer project (tests/Consumers/Fallout.Consumer.Local/— already exists as a sentinel) restores from it and exercises the new bits in a real consumer shape, end-to-end, without publishing externally.Once it works locally, it becomes a CI step on PRs targeting
mainorrelease/vN. The check: "we can build, publish, restore, and consumeFallout.X.M.P-pr.NNN.SHAfrom a clean container."Candidates
Recommendation pending evaluation: BaGet. Active, official Docker image, simplest path to "stand it up in CI for 5 minutes per PR."
Acceptance criteria
docker-compose.yml(or equivalent) at repo root or undertests/integration/spins up the chosen server.dotnet fallouttarget (or script undertests/integration/) packs allFallout.*artifacts, pushes to the local server, and exits with the feed URL.tests/Consumers/Fallout.Consumer.Local/sentinel restores against the local feed and builds — likely via anuget.configpointing athttp://localhost:8080/v3/index.json.12.0.0-pr.NNN.YYYYMMDD.SHAso PR runs don't collide.ubuntu-latest, non-blocking unless we want it to be.Future direction (deferred)
Likely the seed for a devcontainer / Codespaces approach — contributors clone, open in devcontainer, and the local NuGet server is preconfigured with the rest of the dev env (.NET SDK via
global.json,Fallout.Clivia.config/dotnet-tools.json). File the devcontainer follow-up once this base lands.Out of scope