Repository navigation
Move ParameterService onto the BuildContext - #452
Merged
dennisdoomen merged 1 commit intoOct 10, 2026
Merged
dennisdoomen merged 1 commit into
dennisdoomen merged 1 commit into
Conversation
This was referenced Jun 30, 2026
ChrisonSimtian
added
target/vNext
ChrisonSimtian
force-pushed
the
engine/ft4-parameter-service
branch
from
July 26, 2026 10:17
119fee5 to
69b4088
Compare
ChrisonSimtian
added
target/vCurrent
ChrisonSimtian
marked this pull request as ready for review
July 26, 2026 10:18
ChrisonSimtian
added a commit
to ChrisonSimtian/Fallout
that referenced
this pull request
Jul 26, 2026
Runs a fixture build end-to-end, twice in one process, and asserts what the de-static work promised: both runs succeed, the second gets its own context/parameter service/log sink, it opens on an empty sink, and the static facades inside a run point at that run. This is what the original FT-9 commit set out to do. Its unit-level assertions have since landed with the steps they belong to (FT-2 in Fallout-build#451, FT-4 in Fallout-build#452, FT-6 in Fallout-build#453), so what is left here is the end-to-end case they could not cover — and it immediately found the leaked file-sink logger fixed in the previous commit. Verified as a real guard: reverting that fix fails 4 of these 5 specs. Two process-wide inputs are pinned to make a build runnable under a test host — the argument parser (swapped and restored) and the statically-resolved root directory (asserted to carry the .fallout marker, since UpdateNotification prompts for input without it). Both are de-statification candidates in their own right.
ChrisonSimtian
added
target/vNext
ChrisonSimtian
added a commit
to ChrisonSimtian/Fallout
that referenced
this pull request
Sep 4, 2026
Runs a fixture build end-to-end, twice in one process, and asserts what the de-static work promised: both runs succeed, the second gets its own context/parameter service/log sink, it opens on an empty sink, and the static facades inside a run point at that run. This is what the original FT-9 commit set out to do. Its unit-level assertions have since landed with the steps they belong to (FT-2 in Fallout-build#451, FT-4 in Fallout-build#452, FT-6 in Fallout-build#453), so what is left here is the end-to-end case they could not cover — and it immediately found the leaked file-sink logger fixed in the previous commit. Verified as a real guard: reverting that fix fails 4 of these 5 specs. Two process-wide inputs are pinned to make a build runnable under a test host — the argument parser (swapped and restored) and the statically-resolved root directory (asserted to carry the .fallout marker, since UpdateNotification prompts for input without it). Both are de-statification candidates in their own right.
ChrisonSimtian
force-pushed
the
engine/ft4-parameter-service
branch
from
September 4, 2026 10:06
69b4088 to
e7241d7
Compare
Each build run now gets its own `ParameterService`, held on `BuildContext`. `ParameterService.Instance` returns the service of the current run. Outside a run, it returns one shared service, so callers without a run still work. The service has two mutable fields: the arguments read from files, and the arguments read from the commit message. Before, they lived as long as the process, so one run could leave state for the next. Now they are discarded with the run. This is internal plumbing. The static `ParameterService` API does not change. The service still reads the process command-line arguments and environment variables. Passing in a different source for a run is not part of this change. Part of Fallout-build#309. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RJw6L2mf6MpeRBvJaow54b
ChrisonSimtian
force-pushed
the
engine/ft4-parameter-service
branch
from
October 4, 2026 08:15
e7241d7 to
85db4b3
Compare
ChrisonSimtian
added a commit
to ChrisonSimtian/Fallout
that referenced
this pull request
Oct 4, 2026
Runs a fixture build end-to-end, twice in one process, and asserts what the de-static work promised: both runs succeed, the second gets its own context/parameter service/log sink, it opens on an empty sink, and the static facades inside a run point at that run. This is what the original FT-9 commit set out to do. Its unit-level assertions have since landed with the steps they belong to (FT-2 in Fallout-build#451, FT-4 in Fallout-build#452, FT-6 in Fallout-build#453), so what is left here is the end-to-end case they could not cover — and it immediately found the leaked file-sink logger fixed in the previous commit. Verified as a real guard: reverting that fix fails 4 of these 5 specs. Two process-wide inputs are pinned to make a build runnable under a test host — the argument parser (swapped and restored) and the statically-resolved root directory (asserted to carry the .fallout marker, since UpdateNotification prompts for input without it). Both are de-statification candidates in their own right.
ChrisonSimtian
changed the title
dennisdoomen
self-requested a review
October 10, 2026 09:01
dennisdoomen
approved these changes
Oct 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #309 (make
ParameterServiceper run). Step 3 of the engine de-statification work, after #450 and #451. Part of the epic #315.Problem
ParameterService.Instancewas one static object for the whole process. It has two mutable fields: the arguments read from files, and the arguments read from the commit message. They lived as long as the process, so one build run could leave state for the next.Outcome
BuildContexthas a newParametersproperty. Each run gets its ownParameterService.ParameterService.Instancereturns the service of the current run.Instancereturns one shared service. Callers without a run still work.ParameterService.CreateDefault()builds the service in one place.BuildContextand the shared fallback both use it.This is internal. The static
ParameterServiceAPI does not change.Not in this PR
#309 also asks that the engine can run with an injected arguments and environment source. That is not done here. The per-run service still reads the process arguments (
EnvironmentInfo.ArgumentParser) and environment variables. #309 stays open for that part.Specs
Four new specs in
BuildContextSpecs:Instancereturns the current run's service.Instancereturns a stable shared service outside a run.I checked that the specs guard the change. If
Instanceignores the run's service, or every run shares one service, two specs fail in each case.Verification
dotnet build fallout.slnx: 0 errors.Fallout.Build.Specs: 246).--helpand renders its parameters through the per-run service.Stack
#453 and #454 are built on top of this PR. They contain these commits and need a rebase after this PR changes or merges.
🤖 Generated with Claude Code
https://claude.ai/code/session_01RJw6L2mf6MpeRBvJaow54b