Feature request: Resolve Sentry events from GitHub pull requests

[hkdobrev]

Similar to how you can close/fix/resolve GitHub issues from commits and pull requests in GitHub I'd like Sentry to have a bot which listens to commits on the master branch and close Sentry events as fixes get pushed/merged.

We are using such system at Clippings.com which works with the GitHub and Trello APIs to move Trello cards to a done list. We just add "Fixes https://trello.com/c/....` with the corresponding Trello URL in the PR description and the bot which lives on our Trello board is moving the card automatically when the fix is on master.

[ashwin31]

consider gitlab too, we are using gitlab

[dcramer]

I think it's a nice to have, but realistically an event is only resolved in Sentry when it stops happening. Due to this we're pushing in the direction of simply being release-aware and giving you better context of "whats happening in the current version of my application".

[ashwin31]

@dcramer okay, I am eager to try 8.0. Lets see it.

[hkdobrev]

@dcramer When you have a bug logged in Sentry and you fix the bug you would normally mark it as resolved. If it emerges later for whatever reason, it's counted as a regression, you get notified again and it will be unresolved again. I think this workflow would continue to work with or without releases. So I don't think the 0.8 version (which is otherwise great!) or the improvements to release tracking would change it much.

However I realize it's a nice-to-have and it's for the future. It's just that for our team it is be a really-nice-to-have.

Cheers!

[dcramer]

@hkdobrev the main complexity is "what happens if its seen again after you mark it as resolved, but havent deployed the fix?"

[atticoos]

+1

[hkdobrev]

@dcramer

the main complexity is "what happens if its seen again after you mark it as resolved, but havent deployed the fix?"

I see two scenarios:

1. When people merge to master, but deploy only when a deploy/release process is scheduled.
2. When people are using a CI and deploy immediately what's on master, but the Sentry event happens again before the deploy has finished.

In both cases a system could be used which resolves Sentry events when the deploy has finished rather on commit. E.g. a Travis CI after_deploy hook or any other CI hooks.

Also the 2nd case is less probable as most deployments would finish in a few minutes and something which close the Sentry event when merged would work for many organizations (personal opinion).

[hkdobrev]

@dcramer I see you have resolved your concerns beautifully with http://blog.getsentry.com/2015/11/25/resolve-in-next-release.html. 👏

[benvinegar]

We made this happen in 2017: https://blog.sentry.io/2017/05/01/release-commits.html

[hkdobrev]

🙌 🎉 🚀

We were just implementing this fully this week! Great work!

I personally don't see why not closing with "Fixes <Sentry URL>". Now, we need to add the issue short number and also a link for quick access.

[benvinegar]

I personally don't see why not closing with "Fixes "

I suppose we could explore adding that.

[urbanit]

Status?

[kamerat]

I am not sure if I have a wrong setup, but adding fixes <SHORT-ID> in pull-requests does not work for me. However, adding the same in a commit-message does.

My question is: Is it possible to close sentry issues by adding fixes <SHORT-ID> in PR description/comments?

[dcramer]

it should, but you need github integration wired up fully