Skip to content

fix: builds no longer fail when symbol upload or release creation is enabled but no Sentry auth token is available - #5705

Merged
ric-oliv merged 1 commit into
mainfrom
fix/msbuild-no-auth-token
Oct 12, 2026
Merged

ric-oliv merged 1 commit into
mainfrom
fix/msbuild-no-auth-token

Conversation

@jamescrosswell

Copy link
Copy Markdown
Collaborator

PrepareSentryCLI runs sentry-cli info to decide whether the CLI is configured, and skips uploads and release creation if it isn't. Since sentry-cli 2.30.0 (#3203), info prints error: Auth token is required… when there's no token, or error: API request failed when the token is bad or the server can't be reached. The probe's Exec ignored 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 with SentryUploadSymbols, SentryUploadSources or SentryCreateRelease enabled and no token: fork PRs, local Release builds, and docker build without the secret.

  • The probe sets IgnoreStandardErrorWarningFormat="true", so a failing info falls through to the existing skip logic.
  • The probe's stderr is logged at normal importance. A successful build no longer prints the CLI's error: … and "Please attach the full debug log" lines at the default verbosity.
  • The skip message and warning now say that uploads and release creation are skipped.

Closes #5704

Notes for review

  • An invalid or expired token, or an unreachable server, now gives the existing "Sentry API request failed" warning and a successful build, rather than a failed build. That was what the warning was there for, but anyone relying on the failure will notice. -warnaserror still fails the build.
  • The release-creation tests now pass the CLI stub to MSBuild through an environment variable rather than /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

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

codecov Bot commented Oct 12, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.22%. Comparing base (f5891ee) to head (fb3638b).

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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@jamescrosswell
jamescrosswell marked this pull request as ready for review October 12, 2026 03:39
@github-actions github-actions Bot added the risk: medium PR risk score: medium label Oct 12, 2026
@ric-oliv
ric-oliv merged commit deada1c into main Oct 12, 2026
67 of 69 checks passed
@ric-oliv
ric-oliv deleted the fix/msbuild-no-auth-token branch October 12, 2026 08:55
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

risk: medium PR risk score: medium

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MSBuild integration fails the build when no Sentry auth token is available

2 participants