Sentry: linking into github repository via SHA

[phoet]

it would be great to have a seamless github integraton from the sentry stacktrace view.

based on a SHA in the exception environment and the github repo-name you could directly link to github source-code view.

i'm new to sentry and i could not find out if it's possible to do this right now. i used this functionality quite heavily within errbit.

would it be possible to integrate something like this via a plugin? any feedback appreciated.

[dcramer]

I had started looking at doing better, native integration with GitHub recently. The main complication we have with things right now is GitHub is tied to a user, and not a project. I dont honestly have a great answer for that problem. That said, with simple things like "show me this file on GitHub" I think it'd be pretty easy since we're just generating a link and not actually needing to communicate.

[phoet]

@dcramer yeah, IMHO that would be a great addition. especially using a SHA from the exception tags so you can jump directly into the relevant code-path

[dcramer]

@phoet are you passing 'release' as the SHA already? We dont strongly enforce this, but I think we can just say "does the release tag look like a SHA? ok heres a code link"

[phoet]

not yet, but it would make sense

[dcramer]

Looking at the work I have in a local branch, it looks like the main thing that needs to be determined is "what code actually belongs to this repository and should have a link".

[dcramer]

Also its a bit more complex than that.

For example, sentry's code might be ./sentry on the filesystem, but in the repo that maps up to ./src/sentry

[phoet]

@dcramer when using the github plugin, you already have the repo name handy. the source-mapping should be done via a ROOT / PROJECT_ROOT tag and maybe another tag or config setting to map to the relevant source directory. the last mapping is only necessary for the usecase you mentioned. in rails or php projects, you start at the root dir most of the times.

[dcramer]

@phoet giving this a bit more thought:

Client(code_paths={'/path/to/this/project': 'src/project'})

With that said, I think it's probably better to handle this setting on the server.

If we did it on the server I think the same approach:

Code prefix => Repository prefix

I do think we should still aim for an absolute "project root" in all clients, and have that as part of the SDK. Right now we have relative paths and "in_app=True" but that doesnt guarantee what we're looking for, unless we change it's meaning.

[phoet]

That makes sense to me. +1 for the project root.

[percyhanna]

/me bumps

Did anything ever come of this? Would be awesome if I could click on a link in stack trace that brings me to GH link for that SHA/file/line.

[marcomorain]

👍🏻 Rollbar has this feature and it's really handy to be able to click on a line in a stack-trace and link to the line of code in GutHub. The link doesn't always work - sometimes it will try to build a URL for a file that it not in your repo (some third party code). But 9 times out of ten you can link right to the file and line.

[ShonM]

Rollbar accepts config for what is and isn't project source files.

[dcramer]

@ShonM what's configuration look like? We have some spec we wrote up but haven't gotten around to fully implementing.

[ShonM]

https://docs.rollbar.com/docs/github/
https://docs.rollbar.com/docs/source-control#section-server-root

This also groups errors better if you're rotating releases with new directories (releases/1, releases/2, etc).

I misremembered a bit. I thought that it had a configurable black/whitelist, but it's actually just one directory. That's not as flexible as I would prefer. I have backend in src with its vendors in vendor, and frontend in client with its vendors in node_modules, as one example. From the client directory a Node server is booted as well, so it does contain a portion of "backend" code. Under the single root configuration this becomes two (or three) projects. With a black/whitelist, I think this could be just one project. I personally prefer separate projects for the back/front end for teams larger than five or six developers, though.

Hope that helps!