feat(dora): exclude bot/automation accounts from PR Pickup Time calcu… - #9000
Conversation
|
Hi @klesh could you please review and merge pull request. |
|
Hi. Please fix the errors first. |
4351a5c to
b3e1fb3
Compare
|
Hi @klesh, I've addressed the previous issues and pushed the requested fixes. The PR is now waiting for workflow approval before the QC checks can run. When you have a chance, could you please approve the workflows and take another look? Thank you! |
|
Hi. Thanks for the quick response. I reran the test and it was still failing. Please take another look. |
|
Hi @klesh The PR is now waiting for workflow approval before the QC checks can run. When you have a chance, could you please approve the workflows and take another look? Thank you! |
klesh
left a comment
There was a problem hiding this comment.
LGTM
Thanks for your contribution.
Summary
Fixes #8974.
AI-powered code review bots (such as GitHub Copilot, Dependabot, and GitHub Actions) often post comments immediately after a pull request is created. DevLake currently considers the first PR comment as the start of the review process, regardless of whether the comment is from a human or an automated account. As a result, the
PR Pickup Timemetric can become artificially close to zero and no longer represent the actual time taken for a human reviewer to respond.This PR introduces bot account detection and excludes bot-generated comments when calculating the first review event.
Changes
IsBotfield to the cross-domainAccountmodel.is_botcolumn in theaccountstable with a default value offalse.IsBotusing:type == "Bot"when available.[bot]login suffix as a fallback.batchFetchFirstReviewslogic to ignore comments from bot accounts when determining the first review, ensuringPR Pickup TimeandPR Review Timereflect the first human review.Scope
This change currently supports GitHub accounts only.
For other integrations (GitLab, Bitbucket, Azure DevOps, etc.), the
is_botfield defaults tofalse, resulting in no behavioral changes until bot detection is implemented for those providers.Fixes #8974