Skip to content

Pull Requests

A Pull Request (PR) in GuideMode represents a code change that’s being reviewed before merging. PRs are synced from code hosting providers (GitHub, GitLab, Bitbucket) and are central to measuring code review efficiency and deployment velocity.

Pull Requests in GuideMode:

  • Track PR metadata - titles, descriptions, branches, and timestamps
  • Monitor review workflow from creation to merge
  • Sync aggregate metrics - lines added/deleted, files changed, commit counts
  • Link to issues for delivery tracking
  • Connect to deployments for lead time calculations
  • Power DORA metrics like cycle time

Pull requests move through a well-defined lifecycle:

Diagram
StateDescriptionCommon Scenarios
draftWork in progress, not ready for reviewEarly feedback, CI checks
openReady for reviewStandard review flow
mergedCode merged to target branchSuccessful delivery
closedPR closed without mergingRejected, superseded, abandoned
FieldTypeDescription
titlestringPR title/summary
bodystringPR description
urlstringWeb URL to PR
stateenum’open’, ‘closed’, ‘merged’, ‘draft’
numberintegerPR number
isDraftbooleanWhether PR is a draft
FieldDescription
headBranchSource branch (feature branch)
baseBranchTarget branch (main, develop, etc.)
headShaLatest commit SHA on source
baseShaBase commit SHA on target
FieldDescription
mergedWhether PR was merged
mergeableWhether PR can be merged (no conflicts)
mergeCommitShaSHA of the merge commit
mergedByIdUser who merged (GuideMode ID)
mergedByUsernameUsername of merger
FieldDescription
authorIdPR creator (GuideMode user)
authorExternalIdProvider’s author ID
authorUsernameAuthor’s username

PRs track detailed metrics about the code changes:

Diagram
MetricDescription
additionsLines of code added
deletionsLines of code removed
changedFilesNumber of files modified
commitsNumber of commits in PR

These metrics help identify:

  • PR size - Large PRs may need splitting
  • Churn - High deletion count may indicate refactoring
  • Complexity - Many files may increase review time
FieldDescription
reviewerCountNumber of reviewers assigned/participated
commentCountTotal comments (general + code)
reviewCommentCountCode review comments specifically

Individual reviews have their own states:

Diagram
Review StateDescription
pendingReview requested but not started
commentedReviewer left comments (no approval/rejection)
approvedChanges approved
changes_requestedReviewer requested changes before merge
dismissedReview was dismissed

GuideMode tracks several timestamps throughout the PR lifecycle to calculate metrics:

Diagram
TimestampDescriptionUsed For
createdAtWhen PR was openedCycle time start
firstReviewAtFirst review receivedReview velocity
firstApprovalAtFirst approval receivedApproval time
mergedAtWhen PR was mergedCycle time end
closedAtWhen PR was closed (if not merged)Abandonment tracking
updatedAtLast modificationFreshness
MetricCalculationMeasures
Review TimefirstReviewAt - createdAtHow quickly reviewers respond
Cycle TimemergedAt - createdAtTotal time from PR creation to merge
Diagram Diagram

PRs can link to issues they address:

Diagram
Link TypeDescriptionEffect on Issue
fixesPR fixes an issueCloses issue when merged
closesPR closes an issueCloses issue when merged
resolvesPR resolves an issueCloses issue when merged
referencesPR is relatedNo automatic action

These links are detected from:

  • PR description (“Fixes #123”)
  • Commit messages (“Closes #456”)
  • GitHub linking UI

See Issue Linking for cross-tool linking.

PRs are linked to deployments to track delivery:

Diagram

Links are created by:

  • SHA matching - Deployment SHA matches PR merge commit
  • Webhooks - Provider sends deployment events
  • Manual - Explicitly linked

Time from PR creation to merge:

Cycle Time = mergedAt - createdAt

Measures how long code changes take to review and merge.

Time from creation to first review:

Review Time = firstReviewAt - createdAt

Measures how quickly reviewers respond to PRs.

Aggregate measure of change scope:

Total Changes = additions + deletions
Change Ratio = additions / deletions

PRs can have labels for categorization:

FieldDescription
nameLabel name
colorHex color code
descriptionLabel description

Common label uses:

  • Priority indicators
  • Type of change (feature, bugfix, refactor)
  • Team ownership
  • Review status

The metadata field stores provider-specific data:

{
"milestone": {
"id": 123,
"title": "v2.0"
},
"requested_reviewers": ["alice", "bob"],
"ci_status": "success"
}