Automatically associate event/issue with Sentry Release based on git commit hash?

[rowanmoul]

I'm not sure if this is possible, but I was hoping that I could configure the Sentry SDK to include the commit hash of the currently running code/assembly in reported errors, which could then be used to automatically match that error with a Sentry Release created later and linked to that commit (for example, by using this action: https://github.com/getsentry/action-release).

As far as I can tell this is not possible and I can only specify the name of the Sentry Release. Yes the name of the Sentry Release could be a commit hash, but those aren't very human readable.

Context:
We build our application when a git tag is created, and it is built into a container image. Initially the tags are "release candidate" tags (eg, rc_1.0.0). Once candidates have been tested, we re-tag the same commit and container image with a "release" tag (eg r_1.0.0). This ensures the released code is identical to the tested code (as opposed to re-building from source).
I would like to be able to bake the commit hash into the container image during the initial release candidate build and then have sentry still be able to associate errors from that container with the appropriate release, which is not known at build time.

As a work around, I can specify the Sentry Release name via environment variable in my kuberentes manifests, but this is not as clean as it decouples the specified release name from the commit that the container image was built from, and relies me to make sure they actually match.

[jamescrosswell]

@rowanmoul you should be able to use the Sentry CLI to do this:

• https://docs.sentry.io/cli/releases/#commit-integration

You can also do this automatically when building your solution via build properties:

• Allow creating releases and uploading commits from MSBuild #3462

It's worth reading this comment to understand how the Sentry infers the "release" both at build time (to upload debug and source files) and at run time (when sending events to Sentry):

• Allow creating releases and uploading commits from MSBuild #3462 (comment)

[jamescrosswell]

Yes the link I posted to the comment in that PR explains the difference between the release as reported at runtime vs the releases that get created in Sentry by the CLI (during build).

If you want the version to be the commit hash at runtime, one option would be to set the SENTRY_RELEASE environment variable to be equal to your_commit_hash. You can probably get this from your CI system when building the containers and use it to set an environment variable in a layer in the container. Alternatively running sentry-cli releases propose-version will typically yield the commit hash.

Another way: you can make sure the commit hash forms part of the release as determined by one of the things that Sentry will use to infer the release (at runtime). For example, setting the <Version> property also implicitly sets the AssemblyInformationalVersionAttribute in SDK style projects and Sentry will try to read the version information (at runtime) from that attribute. The <Version> property can also be configured by setting the <VersionPrefix> and <VersionSuffix> separately, so it would be possible to store the commit hash in the VersionSuffix without impacting any SemVer versioning you're using for your application more generally.

So there are lots of ways to ensure the commit hash is included in the Release that gets reported to Sentry at runtime!

[rowanmoul]

If I set config.Release [or SENTRY_RELEASE] to "d43fws3", a new release called "d43fws3" will be created when an event is reported from my application, rather than linking that event to the existing release [called [email protected] in the above example] that is linked to that commit hash.

This is the problem that I have, which I am all the more sure is not possible to solve with the current implementation now. (Aside from the workaround that I mentioned in my first post, which I will proceed with for now).

[jamescrosswell]

If I set config.Release [or SENTRY_RELEASE] to "d43fws3", a new release called "d43fws3" will be created when an event is reported from my application, rather than linking that event to the existing release [called [email protected] in the above example] that is linked to that commit hash.

I think that makes sense and is the behaviour people would expect.

The conventional way to pass the commit hash in a version string is by adding it as a suffix (e.g. [email protected]+d43fws3).

[rowanmoul]

True, that is a reasonable expectation when setting the "SENTRY_RELEASE" or similar.

What I was hoping to be able to do, is separately specify the commit hash in some other field (or some special format in the release field) so that the Sentry Client just reports which commit it is running at runtime, not which "Release", and then Sentry's backend matches up events to a release based on that commit hash, without the sentry client needing to know what the release is called.

[jamescrosswell]

I see. You could always add the commit hash as a Tag. Sentry wouldn't distinguish that tag from any other tags or give it special treatment, but that would give you a way to filter events for a particular release by commit hash. At runtime, you could override Sentry's Options.Release property to set this to the version with the commit hash suffix stripped from it.