Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow creating releases and uploading commits from MSBuild #3462

Merged
merged 11 commits into from
Jul 12, 2024
Merged

Allow creating releases and uploading commits from MSBuild #3462

merged 11 commits into from
Jul 12, 2024

Conversation

jamescrosswell
Copy link
Collaborator

@jamescrosswell jamescrosswell commented Jul 4, 2024 •
edited by bitsandfoxes
Loading

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>

@jamescrosswell jamescrosswell marked this pull request as ready for review July 4, 2024 05:41
bitsandfoxes
bitsandfoxes reviewed Jul 5, 2024
View reviewed changes
Copy link
Contributor

@bitsandfoxes bitsandfoxes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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 bitsandfoxes enabled auto-merge (squash) July 12, 2024 11:21
bitsandfoxes
bitsandfoxes approved these changes Jul 12, 2024
View reviewed changes
Copy link
Contributor

@bitsandfoxes bitsandfoxes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's looking awesome!

@bitsandfoxes bitsandfoxes merged commit b07c089 into main Jul 12, 2024
17 checks passed
@bitsandfoxes bitsandfoxes deleted the set-commits branch July 12, 2024 11:21
@jamescrosswell jamescrosswell mentioned this pull request Jul 19, 2024
Merged
@bruno-garcia
Copy link
Member

Is this documented?
image

If not, how would a user discover it?

@jamescrosswell
Copy link
Collaborator Author

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.

@jamescrosswell jamescrosswell mentioned this pull request Jul 25, 2024
Closed
@bitsandfoxes bitsandfoxes mentioned this pull request Aug 1, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@bitsandfoxes bitsandfoxes bitsandfoxes approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Allow uploading commits through set-commits
3 participants
@jamescrosswell @bitsandfoxes @bruno-garcia