search

getsentry / sentry

Developer-first error tracking and performance monitoring
https://sentry.io
Other
38.95k stars 4.18k forks source link

Issue with "Suspect Commit" Feature Identifying Merge Commits #69085

Open chentsulin opened 6 months ago

chentsulin commented 6 months ago

Problem Statement

I have noticed that when the "Suspect Commit" feature is used to identify the commit likely responsible for a bug, it often points to merge commits from the master or main branch, rather than the original commit where the changes were made. This complicates the process of accurately tracing the source of errors and understanding the specific changes that introduced them.

Could you advise if there is a way to configure the feature to bypass merge commits and directly target the actual change commits? If this is not currently possible, I believe it would be a beneficial enhancement to the functionality of your platform.

Solution Brainstorm

No response

Product Area

Issues

getsantry[bot] commented 6 months ago

Assigning to @getsentry/support for routing ⏲️

getsantry[bot] commented 6 months ago

Routing to @getsentry/product-owners-issues for triage ⏲️

scefali commented 6 months ago

@chentsulin can you explain your workflow a bit more? The way we anticipate suspect commits to work is that a person creates a branch with commits, those commits get squashed into the main/master branch as a new commit, then the suspect commit finds that PR and the squashed commit. Is that not your workflow?

chentsulin commented 6 months ago

No. We are using GitHub flow and we have never squashed our commits in PRs. It is our policy for merging PRs.

lobsterkatie commented 6 months ago

Got it, thanks. This seems like a reasonable option to have for merge-based workflows. I've added it to our backlog.

For whoever picks this up: Here are the API docs for pulling commits, to figure out how to tell if something is a merge commit and therefore exclude it: https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28.