Allow creating releases and uploading commits from MSBuild

[jamescrosswell]

Resolves #3058

Details

There are a couple of extra build properties now:

1. SentryCreateRelease
2. SentrySetCommits

SentryCreateRelease

If you set this to true then the Sentry SDK attempts to use the Sentry CLI to automatically create a release when building your project. The release version can be supplied via a separate SentryRelease build property. If no SentryRelease property is provided then the SDK will infer the version automatically from the ApplicationId, AppManifest, InformationalVersion, AssembyIdentity or the commit hash.

For example:

  <PropertyGroup>
    <SentryUrl>...your Sentry URL if self-hosted, or omit this line if using sentry.io...</SentryUrl>
    <SentryOrg>...your org...</SentryOrg>
    <SentryProject>...your project...</SentryProject>
    <SentryCreateRelease>true</SentryCreateRelease>
  </PropertyGroup>

SentrySetCommits

If this property is set then the Sentry SDK will automatically associate commits with the release. By default, the SDK will set commits with the --auto flag but you can override this to provide whatever flags you want via the optional SentrySetCommitOptions property.

For example:

  <PropertyGroup>
    <SentryUrl>...your Sentry URL if self-hosted, or omit this line if using sentry.io...</SentryUrl>
    <SentryOrg>...your org...</SentryOrg>
    <SentryProject>...your project...</SentryProject>
    <SentrySetCommits>true</SentrySetCommits>
    <SentrySetCommitOptions>--local</SentrySetCommitOptions>
  </PropertyGroup>

[bitsandfoxes]

This looks really great! What I don't get: How do we make sure the release reported by the SDK at runtime matches the release created at built time?
Users can set the <SentryRelease> but that has no affect on the build artifact, right? Should it?

[bitsandfoxes]

Can we remove the leading -- for the commit options? It doesn't seem very intuitive having to add those "manually" from a users POV.

[bitsandfoxes]

Just to confirm this: If I were to set a SentryRelease, how'd that end up on the event getting sent at runtime? Other than creating a new release, what does it to?

[jamescrosswell]

Can we remove the leading -- for the commit options? It doesn't seem very intuitive having to add those "manually" from a users POV.

Possibly. I wanted people to be able to pass anything/everything that they could via the CLI, which could be:

• --auto
• --local
• --commit "repo-owner/repo-name@deadbeef"
• --commit "repo-owner/repo-name@from..to"

So yeah, at least all of those examples start with a -- that we could supply automatically.

One other possibility is they want to supply multiple parameters though... so:

• --auto --ignore-missing

In that case, what would we do? From the build settings would we drop the -- from the first parameter but make them supply it for the second? That seems inconsistent. Or we try to do some fancy parsing to work out which of the args needs to be prefixed with a --? That seems fragile.

I figured it was better if we just let them supply the arguments as they would if they were using the CLI.

[jamescrosswell]

Just to confirm this: If I were to set a SentryRelease, how'd that end up on the event getting sent at runtime?

I don't think it does. Similarly, if you set SentryOptions.Release at runtime, this won't end up being used to create a release at build time. So those two mechanisms to manually control either the Release that gets created at build or the Release that gets sent as context with events operate independently of one another.

If you want those things to match, it's probably best not to set the SentryRelease build property or SentryOptions.Release and instead use one of the mechanisms that ensures these things match (environment variable or one of the multiple options for deriving the release from the assembly).

Other than creating a new release, what does it to?

Just what's done by the CLI basically.

We could rename the build property to __SentryRelease if we didn't want people attempting to set this manually. I think we still need some way for them to be able to control the SentryReleaseOptions and SentrySetCommitOptions used during the build though...

[jamescrosswell]

Renamed the SentryRelease build property to _SentryRelease to make it apparent this is not meant to be fiddled with. I also moved it out of the group of properties that people are meant to fiddle with.

[bitsandfoxes]

That's looking awesome!

[bruno-garcia]

Is this documented?

If not, how would a user discover it?

[jamescrosswell]

Is this documented?

If not, how would a user discover it?

No not documented yet. It is demonstrated in the samples but SentryReleaseOptions and SentrySetCommitOptions in particular would benefit from some docs... as would an explanation of the order of precedence for where the release gets resolved from.