fix: Avoid global.json when running dotnet push#601
Conversation
Resolves getsentry#598: - getsentry#598 Pinning the version of of the .NET SDK used to build the sentry-dotnet repo prevents us from making relases, since that version of .NET is not installed on the machine that publishes NuGet packages. We can run `dotnet push` using any version of .NET so this PR simply runs that command from outside the repository working directory.
There was a problem hiding this comment.
@asottile-sentry any tips on how to test this? As far as I can tell, this would only ever be run when we try to make a release from the sentry-dotnet repo.
spawnProcess is well and truly battle tested. uploadAsset is simply a wrapper for this (passing specific arguments). There's no real logic to test. Ultimately, it "passes" the test if those arguments result in a real NuGet package being uploaded to nuget.org... I can't think of any meaningful tests other than that.
There was a problem hiding this comment.
yeah there's not really much to test without copying the implementation details into the test
There was a problem hiding this comment.
In that case, I think this PR is ready. We can make a new release from the sentry-dotnet repository as soon as it's merged to make sure it all hangs together.
|
@asottile-sentry I suspect you might need to merge this (I don't think I have permission... I certainly don't have any merge button).
|
## Summary Fixes #819. Refs getsentry/sentry-dotnet#5250. The automatic version bumping added in #707 invokes `dotnet setversion` with `cwd: rootDir`, so the dotnet host reads any `global.json` in the consumer repo. The release runner won't always have that exact SDK installed — `dotnet` then refuses to launch and `craft prepare` aborts. Other `dotnet` invocations in this target dodge this by spawning with `cwd: '/'` (see #601, #614). That isn't viable here because `dotnet-setversion` operates on files in cwd. Instead, this PR temporarily renames `global.json` to `global.json.craft-bak` for the duration of the call and restores it in a `finally`. The XML-fallback path is unchanged and unaffected. ## Notes for reviewers - An alternative workaround would be to skip `dotnet-setversion` altogether and rely on the xml based version update logic that is currently a fallback. Hard to say which workaround is better. - No existing test file for `nuget.ts` (`src/targets/__tests__/` has no `nuget.test.ts`), so this PR doesn't add one. Happy to add one if you'd like — let me know the preferred shape.
Resolves #598:
Pinning the version of of the .NET SDK used to build the sentry-dotnet repo prevents us from making relases, since that version of .NET is not installed on the machine that publishes NuGet packages.
We can run
dotnet pushusing any version of .NET so this PR simply runs that command from outside the repository working directory.