> I'm wondering what the reasoning is behind suggesting I upload source artifacts to you as part of a release. The blog post even specifically calls out Go, which is what the majority of our application is written in. So from my understanding, uploading artifacts would allow the Sentry UI to show me exactly where we did a Sentry Dump?
For Go, you ultimately compile your application into a binary. This binary doesn't have the source code, but it does retain references to the filenames and line number in the binary's metadata. What this means is, if you send along a stack trace to us, we can tell you that information, but we can't show you what the actual line of code is, or what the surrounding code is. By uploading the sources to us explicitly, then baking in the release version into your compiled binary, we can map those up and show you a stack trace that includes source code. This is relatively the same idea with any modern JavaScript. Typically a project is compiled down into a minified version, or run through a transpiler, etc, and the original sources aren't accessible to us. So it's then necessary to upload to us so we can map things up.
> On the same topic, our current deploy flow makes it a bit hard to upload specific code changes per release. It would be great if Sentry could get the code from Github directly (assuming that I login and give you access to the repo)
We have plans for VCS integrations in the future (GitHub included) that would likely work with releases so we can just use the working directory at a current sha.
So right now when we have a need to send a stacktrace (error or panic) we use Raven-Go's NewStacktrace to create a stacktrace and attach it to the packet we send up. In the UI I see the exception with surrounding lines.
What makes releases different from what we already do? Or, do they do the same thing, but the difference is crafting the stack trace in our code vs just upload the code and letting you figure it out?
> So right now when we have a need to send a stacktrace (error or panic) we use Raven-Go's NewStacktrace to create a stacktrace and attach it to the packet we send up. In the UI I see the exception with surrounding lines.
Yeah, so raven-go will check for the source files on disk first. You must keep your source files along with the binary. :)
For Go, you ultimately compile your application into a binary. This binary doesn't have the source code, but it does retain references to the filenames and line number in the binary's metadata. What this means is, if you send along a stack trace to us, we can tell you that information, but we can't show you what the actual line of code is, or what the surrounding code is. By uploading the sources to us explicitly, then baking in the release version into your compiled binary, we can map those up and show you a stack trace that includes source code. This is relatively the same idea with any modern JavaScript. Typically a project is compiled down into a minified version, or run through a transpiler, etc, and the original sources aren't accessible to us. So it's then necessary to upload to us so we can map things up.
> On the same topic, our current deploy flow makes it a bit hard to upload specific code changes per release. It would be great if Sentry could get the code from Github directly (assuming that I login and give you access to the repo)
We have plans for VCS integrations in the future (GitHub included) that would likely work with releases so we can just use the working directory at a current sha.