# Review Pull Requests on a Quarkus Service

Yes. An agent checks out the pull request, runs ./mvnw verify in each touched quickstart in its sandbox, and posts one review on CDI scopes and Panache queries.

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

## What the agent does

The agent reads how the repository is assembled before it reads the diff, because quarkusio/quarkus-quickstarts is one aggregator over about a hundred independent builds. The root `pom.xml` is `io.quarkus.quickstarts:quickstart-projects`, packaging `pom`, listing every quickstart as a module and adding the `build-reporter-maven-extension` and an `incremental` profile with `gitflow-incremental-builder` 4.6.0 that builds only what changed against `HEAD`. Each quickstart has its own `mvnw`, its own `pom.xml` importing `io.quarkus.platform:quarkus-bom` at `3.40.1.1`, `maven.compiler.source` and `target` at 17, `maven-surefire-plugin` 3.5.4 with `java.util.logging.manager` set to `org.jboss.logmanager.LogManager`, and a `native` profile that turns on `quarkus.native.enabled`, turns off `quarkus.package.jar.enabled` and binds `maven-failsafe-plugin` to `integration-test` and `verify`. The agent runs `./mvnw verify` inside each touched quickstart rather than at the root, which is what the CI does per module and what a reader of the quickstart would do.

`CONTRIBUTING.md` sets the rules the review applies: pull requests target the `development` branch and `main` is reset on each release, every quickstart must have unit tests, every quickstart that supports native mode must have native tests, a pull request that depends on an unmerged Quarkus feature carries `[DO NOT MERGE]` in its title, and a new quickstart must be listed in `README.md`. `.github/workflows/build-pr-development.yml` runs on JDK 21, fails if `git grep` finds a star import in any `.java` file outside `.mvn` and the two markdown files, clones and builds Quarkus `main` when the base is `development`, then runs `./mvnw -e -B -fae --settings .github/mvn-settings.xml clean install -Dstart-containers` and uploads `target/*-reports/TEST-*.xml` on failure. The agent runs the star-import check verbatim and uses the same settings file, which points Maven at a Central mirror.

The test shape is read from the quickstarts themselves. `getting-started/src/test/java/org/acme/getting/started/GreetingResourceTest.java` is a `@QuarkusTest` using REST-assured's `given().when().get("/hello").then().statusCode(200)`, and `GreetingResourceIT` extends it with `@QuarkusIntegrationTest` so the native profile runs the same cases against the built runner. `hibernate-orm-panache-quickstart` depends on `quarkus-hibernate-orm-panache`, `quarkus-rest-jackson` and `quarkus-jdbc-postgresql`, sets only `%prod` datasource properties plus `quarkus.hibernate-orm.sql-load-script=import.sql`, and its `FruitsEndpointTest` lists, deletes and re-lists fruits through both `/entity/fruits` and `/repository/fruits`. With no `%test` datasource configured, Quarkus Dev Services supplies the test database by starting a container, so the agent checks whether the sandbox can start one before counting a database test as run, and says so in the review when it cannot.

The diff is then read with the three questions the prompt names. CDI scopes: `FruitEntityResource` is `@ApplicationScoped` with `@Transactional` on `create`, `update` and `delete` and not on the two reads, so a new resource that holds request state in a field, or a write method without `@Transactional`, is a finding. Reactive versus blocking: a quickstart on `quarkus-rest` and `quarkus-hibernate-orm-panache` runs its endpoints on worker threads, while the `hibernate-reactive-*` and `getting-started-reactive` quickstarts return `Uni` and must not block, so a `Thread.sleep`, a JDBC call or a `.await()` inside one of those is blocking. Panache queries: the entity pattern in `FruitEntity` uses `listAll(Sort.by("name"))`, `findById` and `persist`, and the repository pattern injects `FruitRepository`, an empty `PanacheRepository<Fruit>`, and calls `listAll`, `findById`, `persist` and `delete` on it from `FruitRepositoryResource`; a hand-written HQL string that concatenates request input, or a `findById` whose `null` result is not turned into a 404 as `getSingle` does, gets a finding with the line. One GitHub review is posted per run, quoting the surefire summary for each touched quickstart, separating blocking issues from suggestions, with file and line on every finding. The agent pushes nothing.

## Start it with one API call

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

```json
{
  "agent": "claude",
  "input": "Review this pull request on a Quarkus quickstart repository. Read CONTRIBUTING.md first. Check the branch out, confirm it targets development, run the star-import check from .github/workflows/build-pr-development.yml, and in each quickstart the diff touches run ./mvnw -e -B --settings ../.github/mvn-settings.xml verify. If a touched quickstart's tests need Dev Services and the sandbox cannot start a container, say so rather than skipping silently. Read the diff with the resource classes, the entities or repositories, application.properties and the test classes. Look for beans whose scope does not fit the state they hold, write paths without @Transactional, blocking calls inside endpoints that return Uni or Multi, Panache queries built from unvalidated request input, findById results not mapped to 404, a new quickstart missing unit tests, native tests or its README.md entry, and star imports. Post one GitHub review that quotes each quickstart's surefire and failsafe summary, separates blocking issues from suggestions, and cites file and line for every finding. Do not push commits.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app/pull/42"
    }
  ]
}
```

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

What comes back is a review on the pull request. Its summary says which branch the pull request targets, quotes the star-import check, and for each touched quickstart quotes the surefire summary from `./mvnw verify`, with the failsafe summary when the native profile was requested. Findings follow with file and line in the quickstart they belong to, marked blocking or suggestion, and a scope or transaction finding names the annotation to add.

The transcript keeps the Maven download, every command and its output, the `target/surefire-reports` the build wrote, and the files the agent opened while following a resource into its entity, so when the review says a reactive endpoint blocks, the stack trace or the line is in the record.

Before merging, a reviewer runs `./mvnw verify` in the touched quickstart on the branch, with `-Dnative` if the quickstart supports it, opens each cited line, and decides which suggestions to keep. A test failure, a star import or a pull request against `main` is blocking by default; a naming suggestion is not.

## Run it on every pull request opened

Create an automation in the Project with a `github` trigger on `pull_request.opened` and `pull_request.synchronize`, `branch_patterns` set to `development`, and this prompt. The trigger adds the pull request after the prompt, so each pull request and each push to it gets its own sandbox, its own Maven repository and its own review, and a `read_only` automation can comment but not push.

The review is the result on the pull request; the run is listed in the Project. `max_runs_per_hour`, 1 to 30, bounds a release week when many quickstarts are bumped at once; a fire past the cap is skipped as `rate_limited` and that pull request is reviewed on its next push. The repository's own CI still builds Quarkus `main` and runs the native matrix, which the sandbox does not replace.

## Why run it on Rush?

A quickstart change is small and its proof is expensive: a Maven wrapper per module, a platform BOM download, surefire under the JBoss log manager, a Dev Services container for anything with a database, and a native profile that only the integration test exercises. Reviewers who cannot spare that read the diff and hope. On Rush the agent runs `./mvnw verify` in its own sandbox for exactly the quickstarts the diff touches, keeps the reports, and posts findings that cite them, so a blocking call in a reactive endpoint is shown rather than suspected.

One sandbox per pull request means a change to `getting-started` and a change to `hibernate-orm-panache-quickstart` are built and reviewed at the same time, with separate Maven state, and nothing is pushed to the contributor's branch. The reviewer gets findings with the surefire output attached and the contributor gets the same result CI would give, with the branch policy from `CONTRIBUTING.md` checked up front.

## Frequently asked questions

### Does it build the whole repository?

No. It runs `./mvnw verify` inside each quickstart the diff touches, using that quickstart's own wrapper and `pom.xml`. The root `incremental` profile with `gitflow-incremental-builder` is available for a root build of only the changed modules, and the agent uses it when the diff touches the root `pom.xml`.

### What about tests that need a database or a broker?

Quarkus Dev Services starts the service in a container when no `%test` datasource or connection is configured, as in `hibernate-orm-panache-quickstart`. The agent checks whether the sandbox can start containers first; when it cannot, the review lists the tests it could not run instead of counting them as passed.

### Does it run the native build?

Only when asked in the prompt, since `-Dnative` needs GraalVM or Mandrel, which the quickstart READMEs list as a requirement, and the CI runs native builds on a separate daily matrix. The review notes whether a touched quickstart has an `*IT` class so a maintainer knows the native leg exists.

### Which Java version does it use?

The pull request workflow runs JDK 21 while each `pom.xml` targets source and target 17, so the agent builds on 21 and flags a diff that uses a language feature past 17 or bumps `maven.compiler.source` in one quickstart only.