Release pipeline fails: craft prepare picks up pinned SDK via global.json #5250

Symptom

When the SDK pinned in global.json is newer than (or otherwise absent from) the image Craft runs on, the release workflow fails during craft prepare → automatic version bumping. e.g. run 26224458396 (releasing 6.5.1).

[error] Automatic version bump failed for "nuget" target: Process "dotnet" errored with code 155
STDERR: dotnet: A compatible .NET SDK was not found.
        Requested SDK version: 10.0.203
        global.json file: /home/runner/work/sentry-dotnet/sentry-dotnet/global.json
        Installed SDKs: 8.0.127, 8.0.206, 8.0.319, 8.0.421, 9.0.117, 9.0.205, 9.0.314, 10.0.108, 10.0.204, 10.0.300

Root cause

Craft (v2.26.5) invokes dotnet setversion <version> with cwd: rootDir (the repo). That picks up our global.json, which pins the .NET version (to ensure deterministic builds).

If the GitHub-hosted runner doesn't carry the specific version of .NET we're using (currently 10.0.203 but that shifts frequently) the dotnet host aborts before setversion runs.

Prior occurrences

• Temporarily disable global.json when pushing NuGet packages craft#598 / fix: Avoid global.json when running dotnet push craft#601 — first hit on dotnet nuget push. Fixed by spawning with cwd: '/' so global.json isn't picked up.
• fix: Avoid global.json when running all dotnet commands craft#614 — same issue on dotnet --version; the cwd: '/' workaround was applied to all dotnet invocations in src/targets/nuget.ts.
• feat: Automatic version bumping from configured targets craft#707 — added "Automatic version bumping from configured targets". The new NugetTarget.bumpVersion spawns dotnet setversion with cwd: rootDir, re-introducing the very pattern the previous PRs eliminated, on a new code path.

Proposed fix

This really needs to be addressed in getsentry/craft, but some options:

1. Skip dotnet-setversion and use the existing XML-edit fallback already implemented in the same method. It doesn't shell out to dotnet at all, so global.json becomes irrelevant. This is the cleanest fix.
2. Temporarily move global.json aside for the duration of the dotnet setversion call (can't use cwd: '/' here because the tool operates on the cwd).

Links

• Failing run: https://github.com/getsentry/sentry-dotnet/actions/runs/26224458396/job/77167675585
• Craft source introducing the regression
• Tracking issue raised in sentry-craft:
  • Regression in nuget automatic version bump breaks dotnet releases craft#819