Spike: How to associated Sentry errors with commits, releases, and merge request

Purpose

Determine if and how we can associated Sentry errors with Sentry Releases AND/OR GitLab releases and GitLab merge requests. This will inform implementation and feasibility of the following issues scheduled for %12.7

• Link to associated release on error detail page
• Link to associated merge request on error detail page
• Filter by release
• Filter by merge request

Deliverable

1. Determine if this is possible or not - clearly state this in the Findings section below
2. If it is possible, document findings in the Findings section below and close the spike

Findings

Summary

	Link - possible?	Difficulty	Filter by - possible?	Difficulty
Sentry Release	Yes	Trivial (/already done?)	Yes	Very easy through Sentry's API
GitLab Release	Yes-ish NO*	Not super straightforward. Would require a suspect commit and a pile of assumptions.	Yes-ishhhh NO*	Depends on when suspect commit would be available & probably some DB additions/restructuring. Possibly prohibitively non-performant.
Merge Request	Yes, if the commit was part of an MR. NO*	Pretty simple with a suspect commit.	Yes, if the commit was part of an MR. NO*	Depends on when suspect commit would be available.

Sentry Releases

We can get a Sentry Release for a Sentry Issue directly from the Sentry Issue API.

Linking to a Sentry Release

• This is basically just user-configured. https://docs.sentry.io/workflow/releases/?platform=javascript
• A Release can be designated in Sentry a few ways:
  1. Ahead of time by API or CLI (specifying a range or set of commits)
  2. On the fly based on the first time a release name is seen by Sentry (the release would need to be included in the event)
  • If the Sentry Issue has release information associated with it, it can realistically only be interpreted as a name. If there is a release, there is not necessarily commit data associated with the release.

Filtering by Sentry Release

• Issues can be filtered through the API by including something like release:release-name-or-version-or-whatever in the query param https://docs.sentry.io/api/events/get-project-group-index/
• The main work needed here would be configuring the UI to make that easy

Frontend concerns

Associating errors with releases

• Sentry displays associated releases as both 'first seen release' and 'last seen release'. An error could exist outside this range but not be triggered yet.
• Assuming we want to avoid clutter and do small iterations, 'first release' is the most relevant piece of information for a user.

Multiple filtering

The search/filter component will need to be updated to allow for multiple queries, similar to how the GitLab current merge request and issue searches currently operate. This is already covered in a separate epic &2031.

*Suspect Commits

If we wanted to get access to a commit for an error, that would unlock access to associate errors with Merge Requests (easily) and GitLab Releases (with some finagling). There are a couple of approaches we could take to get commit info, but they're pretty big.

Click here for a detailed walkthrough of what we could do if suspect commits are available.

All of the below assumes that a Sentry instance in configured with Releases with commit info. Without that information, we can't do any of this.

GitLab Releases

We can tie a GitLab Release to a Sentry Error by mapping a Sentry "suspect commit" to the GitLab Release through a series of tenuous inferences.

Linking to a GitLab Release

GitLab Releases are a snapshot associated with a single commit. This means there is no relationship between Releases. Releases can be from various branches and sources, and they can be post-dated. Releases are created exclusively by API request.

So we can try:

1. Determine & list every release in which the commit appears by comparing releases by timestamp.
2. Determine every release in which the commit appears, then only show the earliest with the error.

A major drawback to this approach is that it's not performant at all. It would require looking at commit diffs between every release for a project every time we want to determine which release the commit is associated with. It's not a clean lookup.

Filtering by GitLab Release

Filtering by a GitLab Release would be dependent on the same foundational logic as Linking to a GitLab Release from an individual issue. Compounding the performance issues here, the experience wouldn't be great.

Possible Performance Workarounds

Both options below require invalidating data when new releases are created, as they could be created out of order. The two on either side time-wise would probably be sufficient.

1. Caching (Potentially a lot of data here)
2. Storing the "previous" release or corresponding commits in the DB for faster lookup

GitLab Merge Requests

We can tie a Merge Request to a Sentry Error by mapping a Sentry "suspect commit" to any Merge Requests which contained the commit.

Link to merge request

This is pretty straighforward. If we get a suspect commit from Sentry, we can lookup a merge request directly with the commit. EX) MergeRequestsFinder.new(User.first, commit_sha: 'suspect-commit-290d3272ba8480290359b088589bb4fbfcb16b4b').execute

Caveats: - Merge commits are not associated with a Merge Request. Depending on what Sentry decides the 'suspect commit' is, there may not be anything to associate it with.

Filter by merge request

Fetch all errors & filter on the GitLab side based on the commits associated with the merge request and the error's suspect commits.

This is the spot where merge commits not being associated with an MR could become particularly noticeable. If users use this UI & filter by their own merge request to check for errors, it could be surprising to accidentally miss errors that Sentry associated with the merge commit.

Frontend concerns

Associating errors with releases

• Sentry displays associated releases as both 'first seen release' and 'last seen release'. An error could exist outside this range but not be triggered yet.
• Assuming we want to avoid clutter and do small iterations, 'first release' is the most relevant piece of information for a user.

Multiple filtering

The search/filter component will need to be updated to allow for multiple queries, similar to how the GitLab current merge request and issue searches currently operate. This is already covered in a separate epic &2031.

Performance considerations

Some data is easily fetchable from Sentry and will come back with the issue, when populated:

• the first/last releases
• suspected commit

Other data will take longer to fetch as it involve multiple calls, some of which may not be cached.

• GitLab Release
• Merge Request

These parts of the UI will need to 'pop-in' later or be in a loading state while the rest of the error is displayed.

As mentioned above, search may be prohibitively difficult to implement performantly.

Write our own commit-identifying algorithm

Sentry's suspect commits are based on the filepaths modified in a commit and the files which were most recently changed. We could build on that idea, and develop our own approach for determining where a problem occurred. This would require a place to store that information, however, so we'd need to be ingesting Sentry Issues into the DB.

So this would involve 1) figuring out how to generate a suspect commit and 2) Fetching and maintaining state for all Sentry errors.

Fork Sentry & include suspect commits in the API

We'd definitely need to determine the complexity of making this information available. There could very well be a reason it's not included in any API payloads currently. But if we're considering forking Sentry anyways, this could be an option.