build: Fallout 10.4 across the repo group, pinned exactly - #321
Merged
Conversation
Bumps the build system from Fallout.Common 10.3.5 to 10.4.0, and pins it with bracket notation. The pin matters more than the bump. A bare "10.4.0" in NuGet is a *minimum*, not an exact version, so restore is free to satisfy it with anything higher -- and it did: this repo was silently resolving Fallout.Common 11.0.8, a major version nobody chose, while the csproj claimed 10.3.5. [10.4.0] turns a missing package into an error instead of an unannounced upgrade, which is the whole point of pinning a build system. Side effect worth noting: the build now restores with zero warnings, down from twelve. The drifted 11.0.8 dependency tree was pulling System.Security.Cryptography.Xml 10.0.6, which carries five high-severity advisories; 10.4.0 does not. Verified: restores 10.4.0, compiles clean, and the target graph runs -- Fallout Execution Engine 10.4.0.15. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Test results228 tests 223 ✅ 2m 4s ⏱️ Results for commit 9c0405c. ♻️ This comment has been updated with latest results. |
Reverses the version half of the previous commit. The pin stays; the number was wrong, and CI proved it. What actually happened: this file said "10.3.5", but a bare version in NuGet is a *minimum*, not a match — so every build here has quietly been resolving Fallout.Common 11.0.8. "Bumping" to 10.4.0 was therefore a downgrade from what CI was really running, which is why a version bump could break a green build. 10.4.0 hangs the Test target. It waits on the test process, which does not exit promptly in this repo, then kills it: the build fails with exit 143 roughly 30 seconds after every test has already passed (41 passed, 5 skipped). Reproduced locally as well as on CI, where it also leaves testhost processes alive for minutes -- one reached 20 GB before exiting. 11.0.18 is not the answer either: it moved Fallout.Common.ProjectModel, so Build.cs no longer compiles. That is worth doing deliberately, not as a side effect of a version bump. So: [11.0.8], which is what CI has in fact been green on for months, now recorded explicitly instead of arrived at by accident. The other three repos in the group are pinned to the same version. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ChrisonSimtian
changed the title
Reverts the wrong turn in the previous commit. I moved the group to 11.0.8 because CI had been green on it -- without checking that the entire 11.x line is UNLISTED on nuget.org. Restore still reaches unlisted versions when satisfying a minimum, so "green on 11.0.8" meant CI had been silently building on a withdrawn package. That is the bug, not the baseline. 10.4.0 is the latest listed release (2026-08-07); the search index carries no 11.x at all. So: [10.4.0], which was the ask all along, and the exact pin is what stops a bare minimum from wandering into withdrawn territory again. That leaves the actual problem the first attempt ran into -- 10.4.0 failing the Test target with exit 143 about thirty seconds after every test had passed. Running the same `dotnet test` command directly, with Fallout out of the picture, exits fine. So the tests are not what hangs. Fallout waits for the child's output streams to reach EOF, and MSBuild's reusable worker nodes and build server outlive `dotnet test` while still holding the inherited stdout handle. EOF never arrives, Fallout waits out its grace period, kills the process, and surfaces 143. MSBUILDDISABLENODEREUSE=1 and DOTNET_CLI_USE_MSBUILD_SERVER=0 stop those daemons outliving the command, so the pipes close and the process is reaped. build.sh already passes -nodeReuse:false for the same reason when building the build project itself; this extends it to the test run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ChrisonSimtian
changed the title
4 tasks
Collaborator
Author
|
Raised #322 for the underlying orphaned-process behaviour. The guard in this PR keeps CI green, but it stops the daemons mattering rather than stopping them being left behind — worth separating so the workaround doesn't get mistaken for the fix. |
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
1 participant
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.
Moves every repository in the group onto Fallout 10.4.0, pinned exactly.
10.3.5[10.4.0]10.3.5[10.4.0]+ Pack fix[10.4.0][10.4.0]The pin is the real fix
Version="10.3.5"in NuGet is a minimum, not a match. So this repo declared 10.3.5 while every build — local and CI — was quietly resolving Fallout.Common 11.0.8.That's worse than ordinary drift: the entire 11.x line is unlisted on nuget.org. Restore still reaches unlisted versions when satisfying a minimum, so CI had been silently building on a withdrawn package for months. 10.4.0 is the latest listed release (published 2026-08-07), and the search index carries no 11.x at all.
An exact pin is what stops a bare minimum wandering into withdrawn territory.
Why the first attempt at this PR failed CI
Pinning to
[10.4.0]made the build fail with exit 143, about 30 seconds after every test had already passed (41 passed, 5 skipped, "Test Run Successful"), with no Fallout summary table.Running the identical
dotnet testcommand directly, with Fallout out of the picture, exits cleanly. So the tests aren't what hangs.The cause is process plumbing: Fallout waits for the child's output streams to reach EOF, and MSBuild's reusable worker nodes and build server outlive
dotnet testwhile still holding the inherited stdout handle. EOF never arrives, Fallout waits out its grace period, kills the process, and surfaces 143.MSBUILDDISABLENODEREUSE=1andDOTNET_CLI_USE_MSBUILD_SERVER=0on the test invocation stop those daemons outliving the command.build.shalready passes-nodeReuse:falsefor the same reason when building the build project; this extends it to the test run. The same guard is applied preventively in the other three repos.One breaking change in 10.4
Solution.GetProjectis gone. Only Satisfactory used it, inPack, to list packable projects by name. That list duplicated theIsPackableflags and would have silently missed a third library, so it now packs the solution and lets each project decide — which is what every other target in that file already did.The two new repos had no build system
CI called
dotnetdirectly, so there was no way to run locally what CI ran. Both now havebuild/with Clean → Restore → Compile → Test → Pack → Push, and CI calls./build.sh.While wiring
PackI hit something that would have bitten on first release: neither had Nerdbank.GitVersioning, so every pack emitted1.0.0and the second tagged release would have been silently skipped as a duplicate. Both now derive versions fromversion.json+ git height (0.1.0), withfetch-depth: 0in CI since git height needs full history.Verified
Clean → Restore → Compile → Test → Packgreen end to end on 10.4.0 — CoI 32/32 tests, Outworld Station 36/36, four packages plus symbols each.Worth its own issue
The hang exposed something real underneath: this repo's test run leaves MSBuild daemons holding pipes well past "Test Run Successful". The guard stops it mattering, but it's tolerance rather than absence — locally I also saw a
testhostreach 20 GB before exiting. Happy to raise an issue if you want it chased.🤖 Generated with Claude Code