What the agent does
In a multi-module Spring Boot project like spring-petclinic/spring-petclinic-microservices, most versions live in one place. The root pom.xml inherits spring-boot-starter-parent 4.0.1 and sets properties for the rest: spring-cloud.version 2025.1.0, chaos-monkey-spring-boot.version 4.0.0, jolokia-core.version 1.7.1 and datasource-micrometer.version 2.0.1, imported through dependencyManagement. The eight modules (admin, config, discovery and gateway servers plus the customers, vets, visits and genai services) declare starters without versions and take whatever the parent and the Spring Cloud BOM manage. The agent reads that layout first, because raising the parent moves dozens of managed artifacts at once.
The agent checks each version it controls against Maven Central: the Spring Boot parent, the Spring Cloud release train, each property in the root pom, and the spring-ai.version property (2.0.0-M1) that spring-petclinic-genai-service sets on its own. Spring Boot and Spring Cloud are released as a matched pair, so the agent keeps the release train on a line that supports the chosen Boot version instead of moving each independently. A milestone like Spring AI 2.0.0-M1 is moved only to a newer milestone or the matching GA, and the change is called out.
Before editing, it records a baseline. The repository ships the Maven wrapper (.mvn/wrapper pins Maven 3.9.8), and java.version is 17, which the maven-enforcer-plugin checks in every module with an application.yml. The agent runs ./mvnw test on a JDK 17 and notes which tests already pass. Tests are spread across modules: ApiGatewayApplicationRouterTest, VisitsServiceClientIntegrationTest and FallbackControllerTest in the gateway, PetResourceTest in customers, VetResourceTest and VisitResourceTest in their services. PetclinicConfigServerApplicationTests points at the spring-petclinic-microservices-config Git repository, so it needs network access to GitHub to pass.
Then it applies the bumps one property at a time and runs ./mvnw test after each, with -pl and -am to limit the build to the modules that property touches where that is enough. A bump that fails compilation or a test is set back to its old value, and the failing test class and the first exception are kept. The final pull request is the set of bumps that pass a full ./mvnw test together, run once more from a clean target directory.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Upgrade this Maven project's dependency versions to their latest compatible releases. In the root pom.xml, consider the spring-boot-starter-parent version, spring-cloud.version and every other *.version property, plus any version property a module sets for itself. Keep Spring Cloud on a release train that supports the chosen Spring Boot version, and keep java.version as it is. Run ./mvnw test with the JDK the pom asks for before changing anything and record the baseline. Apply one version change at a time and run ./mvnw test; for every change that fails compilation or a test that passed in the baseline, restore the old value and record the failing test and error. Run ./mvnw test on the final pom from a clean build. Open one pull request listing each bump with its old and new version and each skipped upgrade with the error that blocked it.",
"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 edits pom.xml properties and the parent version, and touches a module pom only where that module sets its own property, as the genai service does for Spring AI. The description has a table of each version property with its old and new value, a section for upgrades that were tried and reverted with the test class and exception, and a note on any milestone or release-candidate version that was moved.
A reviewer checks two things the build cannot: that the Spring Cloud release train matches the Boot version in Spring's published compatibility table, and that runtime behaviour in the gateway (routes and the Resilience4j circuit breaker) still matches what FallbackControllerTest asserts. The Java CI with Maven workflow on the pull request runs mvn -B package on JDK 17, which builds and tests every module. The session's transcript has each ./mvnw run with its output for any reverted bump.
Run it on every start of each week
Send this request from whatever already runs your scheduled jobs: a cron task, a Jenkins timer, or a GitHub Actions workflow with on: schedule. One POST /o/{org}/sessions per repository, each naming its repository in resources, and an Idempotency-Key derived from the repository and date so a retry does not start a second run.
Configure a webhook on the API key to hear back. The run.completed payload carries a session_url; read it for the pull request and post the link to the channel where your team handles upgrades. Properties the agent set back stay at their old values, so the following week's run tries them again.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
A Spring Cloud project's tests start application contexts, a config server that clones a Git repository, and integration tests for the gateway. Running that suite after each of a dozen property changes is slow work that a laptop does badly while someone is also coding on it. In a Rush sandbox the agent has its own JDK and Maven cache, runs ./mvnw as many times as it needs, and every run's output stays in the session record.
A per-dependency bot raises spring-cloud.version in one pull request and the Boot parent in another, and each can go red because it needs the other. The agent proposes the pair together, tests the whole reactor, and leaves out only what fails, so the pull request that arrives is one that can be merged. Several services can get their weekly upgrade at once, up to the key's limit of concurrent runs.
Frequently asked questions
Will it move to a new Spring Boot major version?
Only if you ask. The prompt says latest compatible, which the agent reads as staying within the current Boot major, here 4.0.x and later 4.x releases. A major upgrade needs code migration and belongs in its own request.
Does it change java.version?
No. The prompt keeps it, and the maven-enforcer-plugin in this pom checks it in every Spring Boot module. A dependency that needs a newer JDK than 17 is skipped and its required Java version is noted.
Why does it use ./mvnw when the CI workflow runs mvn?
The wrapper pins Maven 3.9.8, so the agent's build uses the same Maven every time regardless of what the sandbox image has. CI on the pull request still runs its own mvn -B package, which is a second, independent check.
What if a test needs the network?
PetclinicConfigServerApplicationTests reads the spring-petclinic-microservices-config repository from GitHub. If that test already fails in the baseline, the agent lists it as a pre-existing failure rather than blaming a dependency for it.