When does the github integration resolve a sentry issue?

Integrations
1

I have successfully set up the github integration for my project. I create releases and deploys using the sentry-cli and I can see the results of this in the github information associated with new issues and releases in the Sentry web UI. When creating a release, I use the “sentry-cli releases set-commits --auto” command, then I follow that up with an eventual “sentry-cli releases finalize”.

However, I am curious to know when Sentry decides to mark Sentry issues as “resolved” due to any “Fixes SENTRY-123” entries in the release’s commits. I see several likely candidates:

  • When the “set-commits” command provides the commits for the release
  • When a deploy is created for the release (in my case this would be after the “set-commits” step.
  • When the release is finalized with the “sentry-cli releases finalize” command

I’m hoping it’s triggered by the finalize step, as that seems like a clean demarcation with the least chance of prematurely resolving issues just to have them reopen if the event occurs again (which is almost guaranteed if one has pre-production environments that get the code first while the issue is still affecting production). This would also allow one to create the release prior to deploying to staging environments and add commits to the release if more issues are discovered and fixed during pre-production testing.

Does anyone know for certain?

Additionally, does anyone know what purpose the “finalize” command serves? It’s not really clear from the documentation.

2

When pull requests hooks are received links are created between the pull requests and sentry issues. As pull requests are merged sentry tracks the merge commits as well.

Then when commits are added to a release all matching pull request merges are found and referenced issues are resolved. You can see the relevant code here.

Finalizing a release sets the started/released datetimes on the release. See here for what goes on during sentry-cli finalize

3

Awesome, thanks for the code references.

I can see where the resolution is triggered based on the commit messages and PR descriptions as one adds commits to the release here.

And thanks for the confirmation on the scope of the side-effects of the “finalize” operation.

I think in order to minimize the chance of erroneously re-opening issues closed by adding issues to the release, I’ll just add the commits to the release as one of the final steps once the new code has been deployed 100% to prod.