MS build setup does not create releases

[InterstellarStella]

Package

Sentry.Maui

.NET Flavor

.NET

.NET Version

8.0

OS

Android

SDK Version

4.10.0

Self-Hosted Sentry Version

No response

Steps to Reproduce

The user is trying to create a Release from Azure Dev Ops pipeline for their MAUI project. They have followed this article.

The pipeline is now succeeding but the release never gets created. At the end of the logs they see the following warning:

(_CreateSentryRelease target) ->
EXEC : warning : An organization ID or slug is required (provide with --org) [/Users/(...).Maui.csproj::TargetFramework=net8.0-ios]

"/Users/(...).sln" (Publish target) (1) ->
"/Users/(...).Maui.csproj" (Publish target) (11) ->
(_SentrySetCommits target) ->
EXEC : warning : An organization ID or slug is required (provide with --org) [/Users/(...).Maui.csproj::TargetFramework=net8.0-ios]

They are specifying the org and project. Here is the YAML when they try and build for Android:

- task: DotNetCoreCLI@2
displayName: 'Build and sign Android target'
inputs:
command: 'publish'
projects: '**/(...).Maui.csproj'
publishWebProjects: false
zipAfterPublish: False
arguments: '-c $(buildConfiguration) -f net8.0-android -o $(outputDirectory) -p:AndroidKeyStore=True -p:AndroidSigningKeyStore=D:\a\1\s\(...).keystore -p:AndroidSigningStorePass=password -p:AndroidSigningKeyAlias=(...) -p:AndroidSigningKeyPass=password -p:SentryOrg=(...) -p:SentryProject=(...) /p:ApplicationDisplayVersion=$(fullBuildVersionString) /p:ApplicationVersion=$(Build.BuildID)'
env:
SENTRY_RELEASE : $(fullBuildVersionString)
SENTRY_AUTH_TOKEN: '(...)'

They have also tried setting them in the csproj:

<PropertyGroup Condition="'$(Configuration)' == 'Release' Or '$(Configuration)' == 'ReleaseLiveConfig'">

<!-- Configure Sentry org and project -->
<SentryOrg>(...)</SentryOrg>
<SentryProject>(...)</SentryProject>

<!-- Automatically creates a release when building your application. -->
<SentryCreateRelease>true</SentryCreateRelease>

<!-- Automatically associates commits with the release. -->
<SentrySetCommits>true</SentrySetCommits>

<!-- Optionally provide explicit flags to the set-commits command -->
<SentrySetCommitOptions>--local</SentrySetCommitOptions>

<!-- Sends symbols to Sentry, enabling symbolication of stack traces. -->
<SentryUploadSymbols>true</SentryUploadSymbols>

<!-- Sends sources to Sentry, enabling display of source context. -->
<SentryUploadSources>true</SentryUploadSources>

<!-- If you are targeting Android, sends proguard mapping file to Sentry. -->
<SentryUploadAndroidProguardMapping>true</SentryUploadAndroidProguardMapping>

</PropertyGroup>

Expected Result

A release is created in Sentry's releases tab.

Actual Result

They can see in the logs what looks like a successful upload of the "debug information files" but no release.

Creating a .sentryclirc file or using sentry-cli login did not help.

More logs and config without scrubbing in the shadow ticket.

┆Issue is synchronized with this Jira Improvement by Unito

[jamescrosswell]

The error is coming from the sentry-cli when this gets run here:

sentry-dotnet/src/Sentry/buildTransitive/Sentry.targets

Lines 331 to 340 in cdbec91

	<!-- Set release information after the build -->
	<Target Name="_CreateSentryRelease" AfterTargets="Build" DependsOnTargets="_GetSentryRelease"
	Condition="'$(SentryCLI)' != '' and '$(SentryCreateRelease)' == 'true'">
	<Message Importance="High" Text="Creating Sentry Release: $(_SentryRelease)" />
	<Exec
	Command="$(SentryCLIBaseCommand) releases new '$(_SentryRelease)' $(SentryReleaseOptions)"
	IgnoreExitCode="true" ContinueOnError="WarnAndContinue">
	<Output TaskParameter="ExitCode" PropertyName="_SentryCLIExitCode" />
	</Exec>
	</Target>

The $(SentryReleaseOptions) being passed into the CLI get configured here:

sentry-dotnet/src/Sentry/buildTransitive/Sentry.targets

Lines 41 to 51 in cdbec91

	<!-- SentryCreateRelease is implied if SentrySetCommits==true -->
	<SentryCreateRelease Condition="'$(SentrySetCommits)' == 'true'">true</SentryCreateRelease>
	<SentryCreateRelease Condition="'$(SentryCreateRelease)' == ''">false</SentryCreateRelease>
	<!-- This property controls if the Sentry CLI is to be used at all. Setting false will disable all Sentry CLI usage.
	We're explicitly skipping uploads for Sentry projects because they interfere with CLI integration test asserts. -->
	<UseSentryCLI Condition="
	'$(UseSentryCLI)' == ''
	and ('$(SentryUploadSymbols)' == 'true' or '$(SentryUploadSources)' == 'true' or $(SentryUploadAndroidProguardMapping) == 'true' or $(SentryCreateRelease) == 'true' or $(SentrySetCommits) == 'true')
	and '$(MSBuildProjectName)' != 'Sentry'
	and !$(MSBuildProjectName.StartsWith('Sentry.'))">true</UseSentryCLI>

sentry-dotnet/src/Sentry/buildTransitive/Sentry.targets

Lines 99 to 101 in cdbec91

	<SentryReleaseOptions Condition="'$(SentryOrg)' != ''">$(SentryReleaseOptions) --org $(SentryOrg)</SentryReleaseOptions>
	<SentryReleaseOptions Condition="'$(SentryProject)' != ''">$(SentryReleaseOptions) --project $(SentryProject)</SentryReleaseOptions>
	<SentrySetCommitOptions Condition="'$(SentrySetCommitOptions)' == ''">--auto</SentrySetCommitOptions>

I think we need to get a log of the value of that $(SentryReleaseOptions) property. I think that could be done by passing -v diag to build command. If it doesn't have an --org parameter set (which is what the error message suggests) that would imply the $(SentryOrg) property hasn't been set... even though it looks like they're passing this in the arguments to the build ( -p:SentryOrg=(...) - I'm assuming the (...) is a placeholder for the actual org id).

Ultimately, it's some MS Build debugging basically...

[InterstellarStella]

Yes, the (...) are placeholders, and they have filled them in with the correct values.

[munkii]

@InterstellarStella thanks for logging this.

@jamescrosswell we are already passing -v diag for the iOS build and we have the same issue there.

Here's some output from the iOS build logs

   Set Property: SentryReleaseOptions= --project app-maui
   Set Property: SentryCLIUploadOptions= --org magic-bullet
   Set Property: SentryCLIUploadOptions= --org magic-bullet --project app-maui

I'll kick off an Android -v diag now

EDIT
I notice from the logs that Sentry is outputting the following

Task Parameter:Text=Creating Sentry Release: $(fullBuildVersionString)

Is it seeing $(fullBuildVersionString) as a literal rather than a variable?

[munkii]

Set Property: SentryCLIDirectory=C:\Users\VssAdministrator.nuget\packages\sentry\4.10.0\tools
2024-11-26T15:34:04.1065055Z Set Property: _OSArchitecture=X64
2024-11-26T15:34:04.1065408Z Set Property: SentryCLI=C:\Users\VssAdministrator.nuget\packages\sentry\4.10.0\tools\sentry-cli-Windows-x86_64.exe
2024-11-26T15:34:04.1066725Z Set Property: SentryCLIBaseCommand="C:\Users\VssAdministrator.nuget\packages\sentry\4.10.0\tools\sentry-cli-Windows-x86_64.exe"
2024-11-26T15:34:04.1067069Z Set Property: SentryReleaseOptions= --project app-maui
2024-11-26T15:34:04.1067339Z Set Property: SentryCLIUploadOptions= --org magic-bullet
2024-11-26T15:34:04.1067624Z Set Property: SentryCLIUploadOptions= --org magic-bullet --project app-maui
2024-11-26T15:34:04.1068002Z Set Property: SentryCLIDebugFilesUploadCommand="C:\Users\VssAdministrator.nuget\packages\sentry\4.10.0\tools\sentry-cli-Windows-x86_64.exe" debug-files upload
2024-11-26T15:34:04.1068490Z Set Property: SentryCLIDebugFilesUploadCommand="C:\Users\VssAdministrator.nuget\packages\sentry\4.10.0\tools\sentry-cli-Windows-x86_64.exe" debug-files upload --org magic-bullet --project app-maui
2024-11-26T15:34:04.1068998Z Set Property: SentryCLIProGuardMappingUploadCommand="C:\Users\VssAdministrator.nuget\packages\sentry\4.10.0\tools\sentry-cli-Windows-x86_64.exe" upload-proguard
2024-11-26T15:34:04.1069483Z Set Property: SentryCLIProGuardMappingUploadCommand="C:\Users\VssAdministrator.nuget\packages\sentry\4.10.0\tools\sentry-cli-Windows-x86_64.exe" upload-proguard --org magic-bullet --project app-maui
2024-11-26T15:34:04.1069940Z Set Property: _SentryCLICommand="C:\Users\VssAdministrator.nuget\packages\sentry\4.10.0\tools\sentry-cli-Windows-x86_64.exe" info
2024-11-26T15:34:04.1070347Z Set Property: _SentryCLICommand="C:\Users\VssAdministrator.nuget\packages\sentry\4.10.0\tools\sentry-cli-Windows-x86_64.exe" info --no-defaults

Can see the --project and org being "set" but I can also see this call later

"C:\Users\VssAdministrator.nuget\packages\sentry\4.10.0\tools\sentry-cli-Windows-x86_64.exe" releases set-commits --local '5.0.0.16968' --project app-maui (TaskId:5089)

Which results in this error message

EXEC : warning : An organization ID or slug is required (provide with --org) [D:\a\1\s\ProjectBreatheApp.Maui\ProjectBreatheApp.Maui.csproj::TargetFramework=net9.0-android]
2024-11-26T15:34:11.3455930Z The previous error was converted to a warning because the task was called with ContinueOnError=true. (TaskId:5089)

Is this failing because "--org" not being passed to sentry-cli-Windows-x86_64.exe (only --project)? Note this log is from our Android build.

In case it is not clear. We are not explicitly calling sentry-cli-Windows-x86_64 that is part of using the DotNetCoreCLI task with the publish command

[jamescrosswell]

Thanks @munkii - that helps.

... Although it makes no sense. Here's what your logs are saying:

2024-11-26T15:34:04.1067069Z Set Property: SentryReleaseOptions= --project app-maui
2024-11-26T15:34:04.1067339Z Set Property: SentryCLIUploadOptions= --org magic-bullet
2024-11-26T15:34:04.1067624Z Set Property: SentryCLIUploadOptions= --org magic-bullet --project app-maui

And here's the relevant section of the targets file where those properties get set:

sentry-dotnet/src/Sentry/buildTransitive/Sentry.targets

Lines 99 to 104 in cdbec91

	<SentryReleaseOptions Condition="'$(SentryOrg)' != ''">$(SentryReleaseOptions) --org $(SentryOrg)</SentryReleaseOptions>
	<SentryReleaseOptions Condition="'$(SentryProject)' != ''">$(SentryReleaseOptions) --project $(SentryProject)</SentryReleaseOptions>
	<SentrySetCommitOptions Condition="'$(SentrySetCommitOptions)' == ''">--auto</SentrySetCommitOptions>
	<SentryCLIUploadOptions Condition="'$(SentryOrg)' != ''">$(SentryCLIUploadOptions) --org $(SentryOrg)</SentryCLIUploadOptions>
	<SentryCLIUploadOptions Condition="'$(SentryProject)' != ''">$(SentryCLIUploadOptions) --project $(SentryProject)</SentryCLIUploadOptions>

So both SentryReleaseOptions and SentryCLIUploadOptions have exactly the same condition("'$(SentryOrg)' != ''") that is used to determine whether an --org argument gets passed.

This one works:

<SentryCLIUploadOptions Condition="'$(SentryOrg)' != ''">$(SentryCLIUploadOptions) --org $(SentryOrg)</SentryCLIUploadOptions>

But this one doesn't:

<SentryReleaseOptions Condition="'$(SentryOrg)' != ''">$(SentryReleaseOptions) --org $(SentryOrg)</SentryReleaseOptions> 

I'd like to help further, but this defies logic... so I'm a bit stuck.

[bruno-garcia]

There was a bug in the version before 4.11, got fixed here: #3600

[munkii]

We were building with 4.10, I have upgraded to 4.13.0 and we now have a Release being created .

However the version number it is using for the iOS Release is indeed the literal "$(fullBuildVersionString)"

I'll have a look at how we are passing that into the AzDo task

For Android the version number is almost correct with the nhumber wrapped in ''

The release '5.0.0.16982' is the Android one

[jamescrosswell]

However the version number it is using for the iOS Release is indeed the literal "$(fullBuildVersionString)"

Hi @munkii ,

That is more about Azure Pipelines than it is about Sentry. It will come from either how you're passing this as a build argument and/or how you're setting an environment variable:

arguments: '-c $(buildConfiguration) -f net8.0-android -o $(outputDirectory) -p:AndroidKeyStore=True -p:AndroidSigningKeyStore=D:\a\1\s\(...).keystore -p:AndroidSigningStorePass=password -p:AndroidSigningKeyAlias=(...) -p:AndroidSigningKeyPass=password -p:SentryOrg=(...) -p:SentryProject=(...) /p:ApplicationDisplayVersion=$(fullBuildVersionString) /p:ApplicationVersion=$(Build.BuildID)'
env:
SENTRY_RELEASE : $(fullBuildVersionString)

I'm not familiar with Azure Pipelines so can't offer much advice other than the docs.

[munkii]

I have the iOS one working perfectly well now and Android one just has the '' issue which I can probably sort later. Either way we can close this. @jamescrosswell @InterstellarStella thanks for your help