Dataset: Issues & Pull Requests
Entity: Pull Requests, Issues
Field ID: review_approved_at
Type: Datetime
Description: The datetime at which a pull request first met its minimum approval quota from approving reviews. For issues, it is the oldest approval timestamp from resolving pull requests.
Source: Calculated from pull request reviews
Transformation logic:
Pull requests: It is the submission datetime of the first review that allowed the pull request to meet its minimum number of approving reviews to be considered approved.
The minimum number of approving reviews is a configuration parameter that is usually available in each git project. If none were configured, Keypup considers that the minimum number of approving reviews is 1.
Note that pull requests will not be considered as "approved" while there is aCHANGES_REQUESTEDreview still active, even if the number of approving reviews reaches the minimum number of approving reviews. TheCHANGES_REQUESTEDreview must be discarded or re-requested for review first.Issues: It is the oldest "approved at" datetime across all resolving pull requests. Resolving pull requests are pull requests that reference the issue via auto-closing keywords.
From: |
|
Github (PRs, Issues) | Calculated |
Gitlab (PRs, Issues) | Calculated |
Bitbucket (PRs, Issues) | Calculated |
Azure DevOps (PRs, Issues) | Calculated |
JIRA (Issues) | Calculated |
ClickUp (Issues) | Calculated |
Trello (Issues) | Calculated |
Reporting Use Cases
The Review Approved At field is a crucial timestamp that marks the moment a pull request officially meets the required number of approvals, concluding the formal review cycle. It is essential for measuring the duration of your review process and identifying bottlenecks in the final merge phase.
Calculating the Duration of the Review Phase: This field serves as the definitive end-point for the entire review and rework period.
You can measure the "Time to Approval" with the custom formula
(review_approved_at - LEAST(first_comment_after_review_requested_at, first_review_submitted_at)) / DAY(). This captures the full duration from when the first review started until the PR was formally approved.
Measuring the "Merge Time" or "Deployment Lag": This timestamp is the starting point for the final stage of a pull request's lifecycle.
The formula
(merged_at - review_approved_at) / HOUR()calculates how long an approved pull request waits before being merged. A high value for this metric is a clear indicator of a bottleneck in your deployment pipeline, showing that "finished" work is not being shipped promptly.
Filtering for Actionable Work Queues: The presence of this timestamp allows you to create highly specific and actionable reports.
To build a "Ready to Merge" queue, you can create a report of all open pull requests by using a filter where
Review Approved At is not null and Merged At is null. This gives your release managers a clear list of what is ready for deployment.
Analyzing Throughput: You can track the output of your review process over time.
A column chart with
YEAR_MONTH(review_approved_at)as the dimension andCOUNT()as the metric will show you the number of pull requests your team successfully approves each month.