You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Logic for finding reviewer candidates should be as follows:
2
+
- We are lookin for two pairs of people: the primary - with the most author context in the changed lines, and the secondary - who is the most active reviewer other than the primary
3
+
4
+
To find the primary reviewer, we need to come up with a list of candidates who know this code the best, and track how we decided to make them a candidate. This is the fallback/priority order of who should be considered a great primary:
5
+
* Examining the same Github blame history for the previously existing files, consider the top 5 PR's in the size of their overlap with the lines editing this file. The authors of these most recent PR's that overlap are the next priority for the primary reviewer, but only if the author_association shows they still have write access to the repository.
6
+
* The next best reviewer is the most recent author for a merged PR that impacted a file in this directory.
7
+
* The next best reviewer is the most recent author for a merged PR in this project.
8
+
9
+
You'll need to look at the author_association for each author candidate to understand if they have write access and are thus a valid reviewer.
10
+
11
+
To find the secondary reviewer, we need to come up with a list of candidates who know actively review code, and track how we decided to make them a candidate. This is the fallback/priority order of who should be considered a great secondary:
12
+
13
+
* Examining the same Github blame history for the previously existing files, consider the top 5 PR's in the size of their overlap with the lines editing this file. The reviewer of these most recent PR's that overlap are the highest priority for the primary reviewer.
14
+
* The next best reviewer is the most recent reviewer for a merged PR that impacted a file in this directory.
15
+
* The next best reviewer is the most recent reviewer for a merged PR in this project.
16
+
17
+
Every PR should have at least two reviewers. The author of the current PR cannot be a reviewer. The primary and secondary must be different people.
18
+
19
+
When proposing a reviewer for a PR, be sure to log which of these selection mechanisms the reviewer was selected by.
Create a brand new Go program that finds reviewers for GitHub pull requests.
2
+
3
+
- Go code should be written with best practires in a way that emulates what the Go project itself uses; prioritizing advice mentioned on go.dev, including https://go.dev/wiki/CodeReviewComments and https://go.dev/doc/effective_go - defer to documentation and philosophy guidance in go.dev above all other reference material.
4
+
5
+
- Go code should incorporate thoughts from Google's style guide: https://google.github.io/styleguide/go/
6
+
7
+
- Code should be written with tests and unit testing in mind
8
+
9
+
- Code should use the token stored by the gh command line utility, probably by using `gh auth token`
10
+
- Code should have as few external dependencies as possible
11
+
- Logic for finding reviewer candidates should be as follows:
12
+
- We are lookin for two pairs of people: the one with the most context in the changed lines, and the one who most recently approved a PR to this file who is more likely to be active.
13
+
- To find the reviewers with the most context on the changed lines:
14
+
- For the top 3 files with the largest number of changes within this PR:
15
+
- Use the GitHub API v4 to fetch blame data for those files
16
+
- For the lines being changed in each of thone files, look for the top 3 PR's that last changed the lines this PR alters
17
+
- Look at who approved those PR's
18
+
- Rank these approvers in terms of how many lines of this new PR they previously reviewed
19
+
- To find the most active reviewers for these files, look at most recent PR for the top 3 files with the largest number of changes this within this PR. This will be the same fileset as the context list
20
+
- Rank these in order of how big the PR is that they reviewed
21
+
- If the reviewer with the most context is already a reviewer on this PR, and it's been more than 2 days, add the reviewer with the second most context.
22
+
- If the most active reviewer for these files is already a reviewer on this PR, and it's been more than 2 days, add the reviewer who is the second most active.
-`-pr`: Pull request URL or shorthand (e.g., `https://github.com/owner/repo/pull/123` or `owner/repo#123`)
92
-
-`-project`: GitHub project to monitor (e.g., `owner/repo`)
84
+
-`-pr`: Pull request URL or reference
85
+
-`-project`: GitHub project to monitor
93
86
-`-org`: GitHub organization to monitor
94
-
-`-app`: Monitor all organizations where this GitHub app is installed
95
-
96
-
### Behavior Flags
97
-
98
-
-`-poll`: Polling interval (e.g., `1h`, `30m`). If not set, runs once
99
-
-`-dry-run`: Run in dry-run mode (no actual reviewer assignments)
100
-
-`-min-age`: Minimum time since last commit or review for PR assignment (default: 1h)
101
-
-`-max-age`: Maximum time since last commit or review for PR assignment (default: 180 days)
102
-
-`-max-prs`: Maximum non-stale open PRs a candidate can have before being filtered out (default: 9)
103
-
-`-pr-count-cache`: Cache duration for PR count queries to optimize performance (default: 6h)
87
+
-`--app-id`: GitHub App ID for authentication
88
+
-`--app-key`: Path to GitHub App private key file
89
+
-`-poll`: Polling interval (e.g., 1h, 30m)
90
+
-`-dry-run`: Run without making changes
91
+
-`-min-age`: Minimum time since last activity (default: 1h)
92
+
-`-max-age`: Maximum time since last activity (default: 180d)
93
+
-`-max-prs`: Maximum open PRs per reviewer (default: 9)
94
+
-`-pr-count-cache`: Cache duration for PR counts (default: 6h)
95
+
96
+
### Environment Variables
97
+
98
+
For GitHub App authentication:
99
+
-`GITHUB_APP_ID`: Your GitHub App's ID
100
+
-`GITHUB_APP_KEY`: Path to your app's private key file
101
+
-`GITHUB_APP_PRIVATE_KEY_PATH`: (Legacy) Alternative to GITHUB_APP_KEY
102
+
103
+
## GitHub App Setup
104
+
105
+
1. Create a GitHub App in your organization settings
106
+
2. Required permissions:
107
+
- Repository: Read & Write (for PR assignments)
108
+
- Pull requests: Read & Write
109
+
- Organization members: Read
110
+
3. Download the private key when prompted
111
+
4. Note your App ID from the app settings page
112
+
5. Install the app on your organization(s)
104
113
105
114
## How It Works
106
115
107
-
### Reviewer Selection Algorithm
108
-
109
-
The program finds exactly two reviewers for each PR: a **primary reviewer** (with author context) and a **secondary reviewer** (who actively reviews code).
110
-
111
-
#### Primary Reviewer (Author Context)
112
-
113
-
The primary reviewer is selected based on who knows the code best, in this priority order:
114
-
115
-
1.**Blame-based Authors**:
116
-
- Examines GitHub blame history for changed files
117
-
- Considers the top 5 PRs by overlap with edited lines
118
-
- Selects authors of these PRs who still have write access
119
-
- Verifies write access via author_association
120
-
121
-
2.**Directory Author** (fallback):
122
-
- Most recent author of a merged PR in the same directory
123
-
124
-
3.**Project Author** (fallback):
125
-
- Most recent author of a merged PR in the project
126
-
127
-
#### Secondary Reviewer (Active Reviewer)
128
-
129
-
The secondary reviewer is selected based on review activity, in this priority order:
130
-
131
-
1.**Blame-based Reviewers**:
132
-
- Examines the same GitHub blame history
133
-
- Considers the top 5 PRs by overlap with edited lines
134
-
- Selects reviewers/approvers of these PRs
135
-
136
-
2.**Directory Reviewer** (fallback):
137
-
- Most recent reviewer of a merged PR in the same directory
138
-
139
-
3.**Project Reviewer** (fallback):
140
-
- Most recent reviewer of a merged PR in the project
141
-
142
-
### Assignment Rules
116
+
1.**Analysis**: Examines PR changes, file history, and contributor patterns
0 commit comments