Reviewing pull requests on donated compute

Continue reviews pull requests well: feed it a diff, get back a focused list of bugs, regressions, and missing tests. You can run it in CI on its own. Running it through the opub CLI instead puts the model spend on a project's donated compute, so the review shows up as project usage — on a laptop and in GitHub Actions alike.

This setup runs in opubdev/opub-cli. Every pull request gets an automated review, funded the same way maintainer work is.

The whole thing rests on one command:

opub run continue -- -p "Review this diff for bugs and missing tests." --silent

Continue handles the review. opub owns the execution path: it launches Continue with OpenRouter-compatible credentials from a compute key, and because the work starts with opub run, the spend ties back to the configured project. Everything after -- is Continue's own flags.

Get it working locally first

CI is a script you trust enough to automate. Start on your machine.

Install the CLI, point it at a project and compute key, then run:

curl -fsSL https://opub.dev/install.sh | sh

opub setup continue \
  --project opubdev/opub-cli \
  --project-id 4 \
  --compute-key-id 3

opub run continue -- -p "Review my staged changes for regressions and missing tests"

Those IDs are placeholders — use your own. You do not have to hunt for them: when you create a compute key in opub, the page prints that exact opub setup command with your project and key already filled in, ready to copy, and shows the one-time provider key once. Paste that key when opub setup prompts for it.

opub setup stores the provider key in your local credential store and writes Continue's non-secret config. opub run injects the credentials, refreshes local project context, and hands off. Continue's binary is cn; you let opub launch it so the session is project-aware.

Once that returns a sensible review, the CI version is the same two commands with the inputs wired to a pull request.

The workflow

The production workflow lives at .github/workflows/continue-pr-review.yml. It triggers on pull request activity and keeps permissions tight:

name: Continue PR Review

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

permissions:
  contents: read
  pull-requests: write
  issues: write

The review job installs the tools, configures Continue through opub, and runs it:

jobs:
  continue-review:
    if: >-
      github.event.pull_request.draft == false &&
      github.event.pull_request.head.repo.fork == false
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.base.sha }}
          fetch-depth: 1

      - uses: actions/setup-go@v5
        with:
          go-version-file: go.mod
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install opub
        run: curl -fsSL https://opub.dev/install.sh | sh
      - name: Install Continue CLI
        run: npm install -g @continuedev/cli@1.5.45

      - name: Configure opub for Continue
        env:
          OPUB_PROVIDER_KEY: ${{ secrets.CONTINUE_CI_OPUB }}
        run: |
          printf '%s\n' "$OPUB_PROVIDER_KEY" | opub setup continue \
            --project 'opubdev/opub-cli' \
            --project-id 4 \
            --compute-key-id 3 \
            --insecure-storage \
            --provider-key-stdin

      - name: Run Continue review
        run: |
          opub run continue -- -p "$(cat "$REVIEW_INPUT")" --silent > "$REVIEW_FILE"

Same setup and run as the laptop version, with the same project and compute-key IDs. The only real differences: the provider key arrives over stdin from a repository secret (CONTINUE_CI_OPUB) instead of an interactive prompt, and two flags make the run non-interactive and ephemeral — covered below.

Store that key as a GitHub Actions secret first. In your repository, go to Settings → Secrets and variables → Actions → New repository secret, name it CONTINUE_CI_OPUB, and paste your one-time provider key as the value. GitHub's encrypted secrets guide has the full walkthrough. The workflow reads it as ${{ secrets.CONTINUE_CI_OPUB }} and pipes it into opub setup over stdin, so the key never lands in the workflow file or the logs.

Check out the base, not the PR

The most important line in that job is the checkout:

ref: ${{ github.event.pull_request.base.sha }}

The workflow runs on pull_request, not pull_request_target, and it checks out the base commit — never the PR head. The diff and changed-file list come from the GitHub API instead:

gh api -H "Accept: application/vnd.github.v3.diff" \
  "/repos/$GITHUB_REPOSITORY/pulls/$PR_NUMBER" > pr.diff

So the job holds a repository secret — the provider key — but never executes code from the pull request. That ordering, secret present and PR code never run, is the trust model. Reuse it in any workflow that mixes secrets with contributor input.

Maintain an open source project?

opub helps projects receive donated compute.

Have a public open source project with 100 or more GitHub stars? Get $50 in starter donated compute for use with over 30 top coding models.

Register project

Fork pull requests skip the review

The job needs a repository secret, so it cannot safely run for pull requests from forks. A separate job posts a short comment instead:

Continue review is only run automatically for trusted non-fork pull requests because this workflow requires repository secrets.

A fork contributor sees why there's no review instead of guessing. Maintainers can review the branch locally with the same opub run continue they already use.

A predictable prompt and one comment

The prompt asks for a fixed shape so the output is easy to post and easy to re-post:

Review this pull request diff for bugs, regressions, security issues, and missing tests.
Focus on opub invariants around secrets, MCP responses, session linking, and target completeness.
Keep it concise.

Output markdown with these sections exactly:

## Summary

## Findings
- Use bullets. If there are no issues, write `- No actionable issues found.`

## Suggested follow-ups
- Use bullets. If none, write `- None.`

The focus line is project-specific — point it at whatever your codebase actually cares about. The fixed sections are what make the result postable.

The workflow writes that result behind a marker comment:

<!-- continue-pr-review -->

On the next run it finds the marker and edits the existing comment instead of adding a new one. One review per pull request, kept current.

CI tradeoffs worth naming

Two choices in the workflow are CI-specific, and both are on purpose.

--insecure-storage. GitHub-hosted Linux runners often have no system keyring, so the default credential store fails. The provider key goes into OPUB_HOME under $RUNNER_TEMP instead. That is fine here: the runner is ephemeral, the home is temporary, and the job is already secret-scoped. It is not how you would store credentials on a laptop.

Pin the Continue CLI. Continue is pinned to @continuedev/cli@1.5.45 so an upstream release cannot change review behavior mid-stream, which keeps the CI output reproducible. opub installs the current version from opub.dev/install.sh; pin that too if you want the whole pipeline frozen.

What this buys

Running review through opub run instead of calling a model directly means the compute is accounted for. The spend draws from a dollar-limited compute key, lands on the project ledger, and — because the session launched through the CLI — can show Linked on the public project page.

Linked is a narrow claim, on purpose. It says a compute-key session ran for this project. It does not mean opub saw the diff, the prompt, or the review; the diff in this workflow never leaves the runner. (See what Linked means.)

That is the loop worth having: a contributor opens a pull request, Continue reviews it, and the cost is carried by donated compute that is visibly doing the work it was donated for.