Skip to content

Pin the SDK to the 10.0.3xx feature band to stop unattended roll-forward - #640

Merged
ChrisonSimtian merged 1 commit into
Fallout-build:mainfrom
ChrisonSimtian:ci/pin-sdk-feature-band
Aug 19, 2026
Merged

Pin the SDK to the 10.0.3xx feature band to stop unattended roll-forward#640
ChrisonSimtian merged 1 commit into
Fallout-build:mainfrom
ChrisonSimtian:ci/pin-sdk-feature-band

Conversation

@ChrisonSimtian

Copy link
Copy Markdown
Collaborator

Restores CI. Pins the SDK to the 10.0.3xx feature band so the runner image can no longer change our toolchain without us noticing.

What changed

  • global.json: 10.0.100 / rollForward: latestMinor10.0.302 / rollForward: latestPatch.

Why we have to do this for now

rollForward: latestMinor meant CI used whatever SDK the GitHub runner image happened to ship. The image moved to 10.0.400, which loads NuGet.Frameworks 7.9.0.0 into MSBuild. That conflicts with our pinned NuGet.Packaging 6.14.3, which loads NuGet.Frameworks 6.14.3 into the same build-host process. Every ./build.sh run then fails at Compile.

No repository change caused this. The last green run used SDK 10.0.302; the first failing run used 10.0.400.

The real fix is bumping NuGet.Packaging to 7.x — that is #639. It cannot be merged now, because NuGet 7.x drops netstandard2.0, which makes it a breaking change held for the next major (target/vNext).

So this PR is the interim measure. It keeps CI green in the meantime and unblocks every other PR. latestPatch still accepts 10.0.3xx security and bug-fix patches, but will not jump to 10.0.4xx.

Once #639 lands, this pin should be revisited — the band can move forward, and roll-forward policy can be reconsidered deliberately rather than by accident.

Verification

  • With only 10.0.400 installed, dotnet in the repo now refuses to run rather than silently using the broken band. That is the intended behaviour.
  • CI installs 10.0.302 automatically — actions/setup-dotnet is configured with global-json-file: global.json in both build.yml and the publish workflows.

Note for contributors

You need a 10.0.3xx SDK installed locally. If you only have 10.0.400, dotnet will report "A compatible .NET SDK was not found" until you install one.

Part of #638

global.json requested 10.0.100 with rollForward: latestMinor, so CI took
whatever SDK the runner image shipped. The image moved to 10.0.400, which
loads NuGet.Frameworks 7.9.0.0 into MSBuild. That conflicts with the pinned
NuGet.Packaging 6.14.3 and breaks every ./build.sh run at Compile.

The last green run used 10.0.302, so this pins to that feature band.
latestPatch still accepts 10.0.3xx patches but will not jump to 10.0.4xx.

This is a temporary measure. The real fix is bumping NuGet.Packaging to 7.x
(Fallout-build#639), which is a breaking change held for the next major because NuGet 7.x
drops netstandard2.0. Until that lands, the pin keeps CI green and stops the
runner image from changing the toolchain without us noticing.

Contributors need a 10.0.3xx SDK installed. CI installs it automatically via
actions/setup-dotnet reading global.json.

Part of Fallout-build#638

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@ChrisonSimtian ChrisonSimtian added bug Something isn't working target/vCurrent Targets the current version skip-changelog Dont add to the Github Release Notes and removed skip-changelog Dont add to the Github Release Notes labels Aug 16, 2026
@ChrisonSimtian
ChrisonSimtian marked this pull request as ready for review August 16, 2026 11:39
@ChrisonSimtian
ChrisonSimtian merged commit 2b0d7ce into Fallout-build:main Aug 19, 2026
1 check passed
@ChrisonSimtian
ChrisonSimtian deleted the ci/pin-sdk-feature-band branch August 19, 2026 07:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working target/vCurrent Targets the current version

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant