Repository navigation
fix: builds no longer fail when symbol upload or release creation is enabled but no Sentry auth token is available - #5705
Merged
Conversation
PrepareSentryCLI probes with `sentry-cli info` and skips uploads and release creation when it fails. Since sentry-cli 2.30.0 that command prints `error: ...` when it has no token (or the API request fails), and MSBuild parsed that line as a build error despite IgnoreExitCode, so the build failed before the skip could take effect. Fixes #5704 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5705 +/- ##
=======================================
Coverage 75.22% 75.22%
=======================================
Files 516 516
Lines 19022 19022
Branches 3698 3698
=======================================
+ Hits 14309 14310 +1
+ Misses 3858 3857 -1
Partials 855 855 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
ric-oliv
approved these changes
Oct 12, 2026
3 tasks done
This was referenced Oct 13, 2026
This was referenced Oct 18, 2026
jamescrosswell
added a commit
to mentaldesk/truman
that referenced
this pull request
Oct 21, 2026
Dogfood the v7 release candidate. Three workarounds in this repo exist only because of issues that v7 resolves, so they go with it. The job runner moves off the logging integration, which no longer initialises the SDK in v7 (getsentry/sentry-dotnet#5245), onto UseSentry from the new Sentry.Extensions.Hosting package. That also sets the Sentry environment from the host environment (getsentry/sentry-dotnet#5468), so the manual SENTRY_ENVIRONMENT/IsProduction()/IsStaging() resolution is deleted, and it binds the Sentry configuration section itself, so the explicit Dsn assignment goes too. UseSentry has to be registered after ConfigureLogging. It registers Sentry's ILoggerProviders through ConfigureServices, and ClearProviders() silently removes them if it runs later — taking with it the SDK's only initialisation trigger in a host that is never started. Raised upstream as getsentry/sentry-dotnet#5755. The host is now started rather than having its services resolved off an unstarted host, so SentryHostedService initialises the SDK deterministically and closes it on shutdown, instead of initialisation resting on something happening to resolve a logger first. The hand-rolled check-in plumbing becomes SentrySdk.WithMonitorAsync, new in v7. No monitor config is passed, so the schedule continues to be managed in Sentry rather than overwritten from the job. Both Dockerfiles drop their UseSentryCLI=false fallback: since 6.12.1 a missing auth token makes sentry-cli skip the upload with a warning instead of failing the build (getsentry/sentry-dotnet#5705), which is the fork-PR path. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
jamescrosswell
added a commit
to mentaldesk/truman
that referenced
this pull request
Oct 21, 2026
…147) * chore: upgrade to Sentry 7.0.0-rc.2 Dogfood the v7 release candidate. Three workarounds in this repo exist only because of issues that v7 resolves, so they go with it. The job runner moves off the logging integration, which no longer initialises the SDK in v7 (getsentry/sentry-dotnet#5245), onto UseSentry from the new Sentry.Extensions.Hosting package. That also sets the Sentry environment from the host environment (getsentry/sentry-dotnet#5468), so the manual SENTRY_ENVIRONMENT/IsProduction()/IsStaging() resolution is deleted, and it binds the Sentry configuration section itself, so the explicit Dsn assignment goes too. UseSentry has to be registered after ConfigureLogging. It registers Sentry's ILoggerProviders through ConfigureServices, and ClearProviders() silently removes them if it runs later — taking with it the SDK's only initialisation trigger in a host that is never started. Raised upstream as getsentry/sentry-dotnet#5755. The host is now started rather than having its services resolved off an unstarted host, so SentryHostedService initialises the SDK deterministically and closes it on shutdown, instead of initialisation resting on something happening to resolve a logger first. The hand-rolled check-in plumbing becomes SentrySdk.WithMonitorAsync, new in v7. No monitor config is passed, so the schedule continues to be managed in Sentry rather than overwritten from the job. Both Dockerfiles drop their UseSentryCLI=false fallback: since 6.12.1 a missing auth token makes sentry-cli skip the upload with a warning instead of failing the build (getsentry/sentry-dotnet#5705), which is the fork-PR path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat: source maps, readable releases, logs, replay and user feedback Ports the second half of the Sentry blog series back into this repo. Until now Sentry could tell us something broke but not where: frontend stack traces were minified, no debug symbols reached Sentry from the container build, and every release read 1.0.0. Source maps and symbols. The Sentry Vite plugin uploads the SPA's maps, and build.sourcemap becomes 'hidden' so the maps are emitted and uploaded without being advertised to browsers — Sentry resolves them by debug ID. The API Dockerfile's web stage had no secret mounted at all, so add the same BuildKit secret the .NET publish uses; without it the upload silently did nothing. Readable releases. MinVer derives the version from git tags, replacing the bare 1.0.0 that .NET falls back to. The container build has no .git, so CI computes the version and passes it through MinVerVersionOverride, with SourceRevisionId supplying the commit that SourceLink would normally add. Commit association moves from SentrySetCommitOptions=--local, which needs a git history the container does not have, to a set-commits --auto step in CI. Note this repo has no tags yet, so MinVer currently yields 0.0.0-alpha.0.N. Tagging a version is what makes the releases page readable. Structured logs via EnableLogs on the API, the job runner and the browser. Session replay was already registered but recorded nothing: both sample rates default to 0. Sets replaysOnErrorSampleRate and replaysSessionSampleRate. User feedback. A FeedbackDialog using captureFeedback with associatedEventId, so a report lands on the issue the user is looking at. ErrorBoundary no longer renders error.message and error.stack at users, and offers the dialog instead; a footer button opens the same dialog for things that break without throwing, which is often the only way to hear about them. The browser SDK moves from @sentry/svelte to @sentry/sveltekit, which is needed for both the Vite plugin and handleErrorWithSentry. Initialisation moves from lib/sentry.ts to hooks.client.ts, where SvelteKit looks for the handleError hook — the only way to see the errors SvelteKit catches for itself. That supersedes and closes #118, and drops a deprecated $app/env import on the way. Two fixes picked up in passing: the vitest 5 upgrade moved the browser-mode context module from @vitest/browser/context to vitest/browser, which had left page.svelte.test.ts failing on main, and ErrorBoundary was not removing its unhandledrejection listener. Note the v11 SDK flattened the Vite plugin's options: org, project, authToken and telemetry are now top level, not nested under sourceMapsUploadOptions. Closes #118 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: match MinVer's tag prefix to the v-prefixed tags MinVer's tag prefix defaults to empty, so it ignored v0.1.0 and kept reporting 0.0.0-alpha.0.N. CI already invokes minver-cli as `minver -t v`, so the MSBuild integration and CI would have disagreed about the version. Both now use v, and a local build reports 0.1.1-alpha.0.1+<sha>. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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
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.
PrepareSentryCLIrunssentry-cli infoto decide whether the CLI is configured, and skips uploads and release creation if it isn't. Since sentry-cli 2.30.0 (#3203),infoprintserror: Auth token is required…when there's no token, orerror: API request failedwhen the token is bad or the server can't be reached. The probe'sExecignored the exit code but still parsed that line as an MSBuild error, so the build failed before the skip could happen. That broke every build withSentryUploadSymbols,SentryUploadSourcesorSentryCreateReleaseenabled and no token: fork PRs, local Release builds, anddocker buildwithout the secret.IgnoreStandardErrorWarningFormat="true", so a failinginfofalls through to the existing skip logic.error: …and "Please attach the full debug log" lines at the default verbosity.Closes #5704
Notes for review
-warnaserrorstill fails the build./p:SentryCLI. The targets can't clear a global property, so the skip path couldn't be tested the old way. The new cases fail without the fix.🤖 Generated with Claude Code