# Review Pull Requests Automatically in a Phoenix App

Have Rush review a Phoenix pull request with real Mix and database checks, then post precise findings without changing the branch.

[Run this on Rush](https://cloud.getrush.ai/run/review-pull-requests/phoenix/), in a Project that has your repository.

## What the agent does

The agent reviews the supplied pull request against the application it actually changes. In a Phoenix project like hexpm/hexpm, mix.exs:8 requires Elixir ~> 1.20, while .github/workflows/main.yml:88–102 pairs Elixir 1.20.4 and OTP 29.1 with a Postgres service. The agent reads the lockfile and CI configuration, uses mix deps.get and verifies the PR head before reviewing. It does not assume that installing Hex packages is the entire test setup or that a local compiler mismatch is a patch regression.

It traces publishing through the API controller and its authorization order. lib/hexpm_web/controllers/api/release_controller.ex:35–38 requires authentication before fetching and parsing the publish body, then fetches the package. Lines 40–47 authorize package ownership and active organization billing before publish runs. Lines 65–76 delegate to Releases.publish with checksums, audit information and workload identity context. A review of this path needs to explain how a changed branch affects a specific caller or tarball, not merely suggest a stylistic rewrite.

For package API changes, it also reads lib/hexpm_web/controllers/api/package_controller.ex. Lines 17–19 cap per_page and call Packages.search_with_versions; lines 60–70 choose reachable repositories based on the current caller. The agent follows helpers and tests relevant to the diff before claiming that a listing, authorization or serialization change is safe. A package visibility bug needs a caller-and-repository scenario; a publish bug needs a request and validation scenario. Those findings should not be collapsed into a generic warning about security.

It runs focused ExUnit coverage and mix test against disposable Postgres state. mix.exs:193 aliases test to database creation, schema loading and migration before the test runner. config/test.exs:88–95 selects hexpm_test with Ecto.Adapters.SQL.Sandbox, while lines 5–13 configure memory-backed storage buckets. Existing tests show the boundary: test/hexpm_web/controllers/api/release_controller_test.exs:44–68 posts a tarball, checks the response, reads the stored package and checks audit data. The review must distinguish those database-backed assertions from external services configured as test doubles. The agent posts one sourced review and pushes no commits.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "codex",
  "input": "Review the Phoenix pull request identified by the URL, base SHA and head SHA the caller appends below. Require the PR identity and verify the checked-out head. Read mix.exs, mix.lock, CI and test configuration, then install dependencies with mix deps.get using compatible Elixir and OTP. Review changes to package publishing and API controllers with surrounding authorization, repository scope, persistence and tests. Use disposable Postgres, never production data; run relevant ExUnit tests and mix test, noting the alias's database setup. Post one GitHub review with current-head file-and-line findings, a concrete failure scenario for each, blocking issues separated from suggestions, exact test results and limits of test doubles. If posting is unavailable, return the review and state it was not posted. Do not change source, push commits, publish packages or merge.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

The result is one review on the caller's PR and a session answer describing the commands and observed outcomes. Each finding points to the current diff and explains the affected request, identity, package or repository. For publishing changes, it connects validation and authorization order to the observable result. For listing changes, it identifies the caller scope and returned data. Optional cleanup suggestions remain separate from defects that should prevent merging.

The maintainer checks that the PR head matches the reviewed revision, that Postgres setup completed and that the full mix test result is accurately reported. The review states which external boundaries use test implementations, so passing ExUnit coverage is not mistaken for a real package publication or live billing check. If the agent cannot post to GitHub, the returned review is clearly marked unposted. This page specifies the requested work without claiming any review, test pass or public hex.pm action occurred.

## Run it on every Phoenix pull request opened

A GitHub webhook receiver you control validates pull_request.opened deliveries and filters the approved Phoenix repository. It appends the PR URL and base/head revisions to input, then starts one POST /o/{org}/sessions request. Install the Rush GitHub App on your own application before using its repository as the resource. The public Hex project supplies examples of the code path, not an external repository the request should modify.

Deduplicate deliveries for the same head and decide explicitly whether subsequent updates deserve a new review. Read the result or process the API key's completion webhook to recover the review link and validation summary. This job authorizes posting one review; it does not authorize publishing a release, altering repository settings or merging the pull request.

## Why run it on Rush?

Phoenix review can need a compatible BEAM toolchain, native dependencies and disposable Postgres before a short controller diff can be evaluated. Rush provides a cloud sandbox for that checkout and test state, leaving the maintainer's local database and working branch untouched. The agent can examine authorization order and persisted audit behavior while the maintainer focuses on the product decision.

Separate PRs can run their checks independently within the key's concurrency allowance. The session transcript retains Mix commands and their output, including database preparation failures, instead of reducing the review to an unsupported pass/fail sentence. That evidence helps the maintainer distinguish a real package-controller defect from an environment mismatch or a test-double limitation. The final judgment remains anchored to the reviewed revision.

## Frequently asked questions

### Does mix test need a database in this application?

Yes. The inspected test alias creates, loads and migrates the database before ExUnit runs. Use a disposable Postgres instance with test configuration, not a production connection.

### Will the review publish a test package to hex.pm?

No. The request forbids package publication and uses controlled test data. The test configuration uses memory-backed storage buckets, so the review should clearly distinguish local test behavior from a real registry action.

### Can passing controller tests prove every external integration?

No. The application configures several external boundaries with test implementations. The review reports that limit and avoids claiming live storage, billing or HTTP verification from local ExUnit results.

### Does the agent change code to resolve its findings?

The review request forbids source changes and pushed commits. It posts findings with concrete failure scenarios and exact line references. A maintainer can authorize a separate implementation task after assessing them.