Resolving issues via commits *via linked issue tracker*?

Integrations
1

Hi folks,

I assume this is the place to discuss https://blog.sentry.io/2017/05/01/release-commits.html given the bit at the end. (But I’m not sure since I don’t see a topic category for “new releases”? Anyhow.)

Most of this commit-integration stuff sounds great. The only thing I’m not enthused by is the suggestion that we start adding fixes <short-id> to our commit messages, because we use Asana as our issue tracker. That means that when we see a Sentry issue that we’re going to fix, we link it with an Asana issue (creating one if necessary—love that you can do that from the Sentry issue page!) and when we fix the Asana issue, we already put fixes <Asana URL> in the message (which causes Asana to annotate the matching issue with a reference to the commit).

I don’t want to start doubling up on commit metadata. That’d also be an end-run around Asana—which, I get it, makes sense as you build out your own issue-tracking functionality—but it doesn’t seem to play well with your existing support for other issue trackers.

If the Sentry user links a Sentry issue with an issue in another system e.g. Asana, can you detect when that’s closed and close the Sentry issue? That seems like the ideal extension of your support for linking other issue trackers.

Thanks,
Jeff

P.S. Prior art: Mute issue when jira is assigned and resolve when closed. Doesn’t augur well for this request but I figured I’d ask specifically how it related to your new commit-integration stuff.

2

If the Sentry user links a Sentry issue with an issue in another system e.g. Asana, can you detect when that’s closed and close the Sentry issue?

That seems really unrealistic.

AFAIK, Sentry will ignore other “fixes” messages unless they strictly match an issue callsign (e.g. JAVASCRIPT-12A). I think the format is unique enough that someone should be able to distinguish between Asana and Sentry “fixes” statements.

Also, I think we’ll explore ways to say “fixed in ” from the UI in the future (e.g. similar to “resolved in next release”).

3

I think the format is unique enough that someone should be able to distinguish between Asana and Sentry “fixes” statements.

Agreed that the formats are distinguishable, but I think that’s a moot point because we don’t want to double up on commit metadata. We use your linking feature to mean “this other issue is the source of truth” so after that, ideally, we’d only have to say that the other issue was closed (to in turn close the Sentry issue).

I think we’ll explore ways to say "fixed in " from the UI in the future (e.g. similar to “resolved in next release”).

Say more? Fixed in what?