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.
consider gitlab too, we are using gitlab
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".
@dcramer okay, I am eager to try 8.0. Lets see it.
@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!
@hkdobrev the main complexity is "what happens if its seen again after you mark it as resolved, but havent deployed the fix?"
+1
@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:
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).
@dcramer I see you have resolved your concerns beautifully with http://blog.getsentry.com/2015/11/25/resolve-in-next-release.html. :clap:
We made this happen in 2017: https://blog.sentry.io/2017/05/01/release-commits.html
馃檶 馃帀 馃殌
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.
I personally don't see why not closing with "Fixes
"
I suppose we could explore adding that.
Status?
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?
it should, but you need github integration wired up fully
Okey, then probably I am missing adding commits manually since I am using the webpack plugin.
Maybe https://github.com/getsentry/sentry-webpack-plugin/pull/139 would fix it for me 馃し鈥嶁檪
Thanks for the reply @dcramer
Most helpful comment
We made this happen in 2017: https://blog.sentry.io/2017/05/01/release-commits.html