Skip to main content
Pull Requests (PRs) are the core data entities in the PullRule application. Every feature, view, integration, and workflow in PullRule is centered around these units. This page provides a detailed overview of how Pull Requests are managed, enriched, and used within the platform.

​
Automatic syncing from integrations

PullRule seamlessly connects with popular source control providers including:
  • Github
  • Bitbucket
Once integrated, PullRule automatically syncs all pull requests from your repositories. This means you never need to manually import or track PRs yourself; the system keeps everything up-to-date near real-time.

​
Pull request members

Each pull request in PullRule is associated with a “member”.
These members are distinct from the users in your organisation and are not billed as users.
Members represent the identity tied to the pull request (e.g. the person who created or is responsible for it in the original repository). This abstraction allows PullRule to analyse and display PRs even for contributors outside your organisation, such as open-source collaborators or external contractors.

​
Filtering and searching

To help you work efficiently with a large number of pull requests, PullRule offers powerful filtering and searching capabilities. You can narrow down visible PRs by applying filters via the filter button on the pull request overview page. Common filter options include:
  • Status: Filter by open, closed, or merged PRs
  • Member: View PRs by specific members
  • Repository: Focus on PRs from particular repositories
  • Created date: Find PRs created within a specific time frame
  • Merged date: Locate PRs merged during a certain period
Looking for a specific pull request? Use the search bar next to the filter button to search PRs by their title. This search is instant and fuzzy-matched to help you quickly find relevant PRs without needing exact titles.

​
Volatile files

Volatility score is only available for users on “Growth” or “Scale” plans.Volatile files are indexed daily for organisations on the “Growth” plan and hourly for organisations on the “Scale” plan.
Volatile Files in PullRule highlight the files in your codebase that change frequently across multiple pull requests. These files tend to accumulate risk, slow down reviews, and signal architectural hotspots. By tracking these areas of high activity, Volatile Files help engineering teams identify:
  • Refactoring candidates
  • Ownership ambiguities
  • Potential sources of merge conflicts
  • Code that disproportionately impacts velocity

​
What makes a file volatile?

A file is classified as volatile when it exhibits:
  • High change frequency: Modified in a large number of pull requests over a given time window (e.g., 30 or 90 days).
  • Contributor spread: Touched by many different authors.
  • Review noise: Often included in otherwise unrelated PRs.
PullRule calculates a volatility score for each file based on the following formula: 
Volatility score = recency weighted change count × unique authors
Recency weighted change count = ∑ e^(–λ × days ago)
The volatility score is also weighted by the recency of changes (weight = e^(-λ * days ago)), where λ is a decay factor that determines how quickly the score decreases over time. This ensures that recent changes have a greater impact on the score than older changes.

​
Example

If a file was changed 10 times in the last 30 days by 4 different people, and most of those changes were recent, it would receive a higher volatility score than a file with the same number of changes all done by one person last month.