Build an AI Pull Request Reviewer with GitHub Actions and DigitalOcean

You will create a GitHub Actions workflow that reviews a pull request diff with DigitalOcean Serverless Inference and posts one comment titled “Advisory AI pull request review.” A later push updates that same comment. The success condition is visible and modest: one non-blocking comment on a same-repository pull request.

This is a second set of eyes, not a merge gate. It can identify a likely unsafe input path, missing edge case, or suspicious change, but it never approves, rejects, requests changes, or merges a pull request. A human must inspect the cited lines and make the decision.

This guide assumes you can create a branch, commit a small change, and open a pull request. You also need a GitHub account that can create repository secrets, a DigitalOcean account with Serverless Inference access, and Node.js 22.6 or newer if you want to run the included checks locally.

Start in a disposable repository or a small test branch. Do not put production credentials, customer data, private logs, or a full repository export into this experiment. The reviewer intentionally sends only a filtered pull request diff, but a secret committed in that diff is still a secret leak.

1. Open the companion repository and select Use this template. This gives you the workflow, TypeScript reviewer, fixtures, tests, lockfile, README, and MIT license in one repository. It avoids the error-prone “copy three files” setup.

2. In the DigitalOcean control panel, open INFERENCE → Manage → Create model access key. Select only the tutorial model you want to use; verify its current model ID in the Model Catalog. Copy the generated secret now: DigitalOcean shows it only once.

3. In your new GitHub repository, open Settings → Secrets and variables → Actions. Select New repository secret, name it DIGITALOCEAN_TOKEN, paste the one-time key, and save it. Optionally add DIGITALOCEAN_MODEL as a repository variable when you want a model ID other than the starter default.

4. From the default branch, create a branch such as test-ai-review. Change a small source or documentation file that is not a lockfile, commit, push, and open a non-draft PR back to the same repository. Do not use a fork for this first test.

5. Open the PR’s Actions tab. When the job finishes, return to Conversation. You should see one comment titled “Advisory AI pull request review.” Push a second small commit and confirm that the same comment is replaced, not duplicated.

The status-handling and redaction fixes are published on the companion default branch. The local command pins the reviewed revision; if you already created a template repository, update src/review.ts and its tests before repeating the PR check.

The workflow runs only on pull_request, skips drafts and forks, and has only contents: read and pull-requests: write permissions. It checks out the base SHA, not the contributor branch. That means npm ci and npm run review use the trusted reviewer files already on the base branch; no pull-request code is executed.

The actions are pinned to immutable commit SHAs, while their comments retain readable release names. The job uses continue-on-error, so an unavailable model or malformed response cannot block a merge. GitHub’s normal fork behavior also withholds repository secrets; the explicit fork check keeps that boundary obvious.

The script excludes common generated and binary files and limits the diff size before requesting a review. It redacts recognizable token patterns and PEM private-key blocks, including generic PRIVATE KEY, RSA, OPENSSH and ENCRYPTED forms. Pattern matching cannot detect every secret; only submit code your team permits the model to receive.

The comment reports completed, no-included-changes, invalid-response or request-failed. Only a completed review with an empty findings array says no actionable findings. Malformed or incomplete JSON produces an incomplete-review message; model-request errors produce an unavailable-review message. All remain advisory.

Use the matching symptom below. Do not loosen the fork restriction or replace the trigger with pull_request_target to make a secret available.

Review the first twenty to fifty comments with the engineers who own the code. Track whether each finding was useful, a false positive, a duplicate, or missed a known risk. Tighten the file policy and prompt when feedback is vague; add deterministic tests or linters for mechanical rules.

Keep the reviewer advisory in v1. Branch protection, tests, static analysis, and human review must remain separate controls. Do not use this workflow for regulated data, production credentials, or a policy that requires deterministic enforcement. You can disable it by removing the workflow and the repository secret.