Summary

The automatic version bumping added in #707 re-introduces the global.json pickup problem that #601 and #614 previously eliminated for the nuget target.

We've deliberately used DOTNET_SPAWN_OPTIONS = { cwd: '/' } elsewhere in this file to avoid this until now. I don't think that can work with setversion though, because it operates on files in cwd.

Prior occurrences

• Temporarily disable global.json when pushing NuGet packages #598 / fix: Avoid global.json when running dotnet push #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 #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 #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.

So this re-surfaces whenever the SDK pinned in global.json is newer than (or otherwise absent from) the image Craft runs on.

See linked issue in sentry-dotnet repo:

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

Brainstorming

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.
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).

Related

Downstream tracking issue:

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