What the agent does
In quarkusio/quarkus-quickstarts, every one of the 114 top-level directories is a separate Quarkus service with its own pom.xml and Maven wrapper (Maven 3.9.11). This request names two: hibernate-orm-panache-quickstart and rest-json-quickstart. Both import the io.quarkus.platform:quarkus-bom at quarkus.platform.version 3.40.1 and use the same property for quarkus-maven-plugin, with surefire-plugin.version 3.5.4. Because the BOM manages every Quarkus extension version, quarkus-hibernate-orm-panache, quarkus-rest-jackson and quarkus-jdbc-postgresql in the Panache service declare no version of their own, and one property moves them all.
The agent runs quarkus update in each directory (or ./mvnw quarkus:update, the same tool through the Maven plugin). It reads the platform version, picks the latest release, and applies the automated rewrite rules Quarkus publishes for each version in between: renamed configuration properties in application.properties, moved packages, changed dependencies. The agent reads the diff the tool produces rather than accepting it blindly, and checks the migration guide for each minor release it crosses for anything the tool marks as manual.
The two poms also differ in ways that matter. The Panache service sets maven.compiler.release to 17 and also configures maven-compiler-plugin with source and target 11 and parameters=true, which RESTEasy needs. rest-json-quickstart sets maven.compiler.source and target to 17 instead. The agent leaves those as they are unless the new Quarkus requires a newer Java, and if so it names the requirement in the pull request. In application.properties, the Panache service only configures a datasource under the %prod profile, so in tests Quarkus Dev Services starts a PostgreSQL container on its own; that needs a container runtime in the sandbox, and the agent reports it if it cannot start one.
Then it runs ./mvnw verify in each directory. In JVM mode that compiles, runs FruitsEndpointTest in the Panache service and FruitResourceTest and LegumeResourceTest in rest-json through surefire, and packages the app. The *IT classes are bound to failsafe only in the native profile, so they need -Dnative and a GraalVM or Mandrel build; the agent runs that only when the prompt asks. Any extension or plugin change that fails is reverted with its error kept, and the remaining bump is verified again from ./mvnw clean verify.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Upgrade Quarkus to the latest compatible version with quarkus update (or ./mvnw quarkus:update), working in hibernate-orm-panache-quickstart and rest-json-quickstart only. Run ./mvnw verify in each before changing anything for a baseline. Apply the update, read the changes it makes, and check the Quarkus migration guide for every minor version crossed; make any manual change it lists. Keep the Java settings in each pom unless the new Quarkus needs a newer Java, and say so if it does. Tests in the Panache quickstart use Dev Services for PostgreSQL, so make a container runtime available or report that it is missing. Run ./mvnw clean verify in each quickstart after the upgrade. Leave out any upgrade that breaks the build or tests and say why. Open a pull request with one line per bump.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- 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.
- 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.
- 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 pull request changes quarkus.platform.version in both poms, any plugin version properties the update raised, and the source or configuration files quarkus update rewrote. One line per bump gives old and new version. A second list shows each code or configuration change with the migration guide entry it comes from, and a third lists anything the agent did not do, such as a manual migration step it judged risky or the native-mode integration tests it did not run.
A reviewer reads the configuration property changes in application.properties first, since renamed keys that are missed fail at startup rather than at build time. They then check that CI on the pull request passes; the repository's PR workflow runs ./mvnw clean install with -Dstart-containers, which starts the containers integration tests need. The session transcript has each ./mvnw verify run with its output.
Run it on every new Quarkus platform release
Quarkus ships minor releases often, so tie the run to the release instead of the calendar. A small job that checks the io.quarkus.platform:quarkus-bom metadata on Maven Central, or a weekly cron that does the same, sends POST /o/{org}/sessions with this request for each Quarkus service when the latest version changes. Put the Quarkus version in the Idempotency-Key so one release starts one run per repository.
Configure a webhook on the API key. Your handler gets run.completed, reads the session for the pull request, and posts it with the Quarkus version in the title. A service that could not be upgraded this time gets the same request on the next release.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
quarkus update downloads the rewrite rules for every version crossed and the build pulls a new set of extensions, and Dev Services starts PostgreSQL for the tests. Doing that for several services on a laptop fills the Maven cache and the container runtime with versions nobody else is using. In a Rush sandbox the agent has its own JDK, Maven repository and containers, runs ./mvnw as often as the work needs, and keeps every command's output in the session.
The update tool does most of the code changes, but someone still has to run the tests, read the migration guide and decide what to leave out. The agent does all three and opens a pull request that says what changed and which guide entry it came from. Several Quarkus services can be upgraded at the same time, each in its own run, within the key's concurrency limit.
Frequently asked questions
What does quarkus update change in my code?
It raises the platform and plugin versions and applies automated rewrites for each version crossed, such as renamed configuration properties and moved packages. The agent reads that diff and adds any manual steps the migration guide lists, then names each one in the pull request.
Do the tests need Docker?
In hibernate-orm-panache-quickstart, yes. The datasource is configured only for the prod profile, so in test mode Quarkus Dev Services starts PostgreSQL in a container. If no container runtime is available, the agent says those tests could not run instead of skipping them silently.
Will it run native-mode tests?
Not by default. The *IT classes only run under the native profile with a GraalVM or Mandrel build, which is slow and needs its own toolchain. Add it to the prompt if you want native builds checked as part of the upgrade.
Can it upgrade every quickstart at once?
It can, but each directory is its own Maven project, so a run over all of them is long. The prompt names two; for more, send one request per group of services so each pull request stays reviewable.