# Upgrade Spring Boot 2.6 to Spring Boot 4

An agent upgrades Spring Boot 2.6 toward Boot 4 using the official guides, runs tests after each step, and opens a PR with changes and open decisions.

[Run this on Rush](https://cloud.getrush.ai/run/upgrade-framework-major/spring-boot-2/), in a Project that has your repository.

## What the agent does

For a Spring Boot 2.6 app like gothinkster/spring-boot-realworld-example-app, the agent reads build.gradle and the project layout first. The build applies org.springframework.boot version 2.6.3, io.spring.dependency-management 1.0.11.RELEASE, Java sourceCompatibility and targetCompatibility 11, MyBatis spring-boot-starter 2.2.2, Netflix DGS graphql-dgs-spring-boot-starter 4.9.21, Flyway, JJWT 0.11.2, joda-time, sqlite-jdbc and Lombok. Spotless 6.2.1 formats Java with googleJavaFormat. Application code lives under src/main/java/io/spring with api, application, core, graphql and infrastructure packages; RealWorldApplication.java is the entrypoint. Tests under src/test/java/io/spring cover APIs (ArticlesApiTest, UsersApiTest, CommentsApiTest and more) and MyBatis repositories, using JUnit Platform (tasks.named('test') { useJUnitPlatform() }) and Rest Assured.

A jump from 2.6 to 4 crosses multiple Spring Boot majors. The agent follows the official upgrade guides in sequence (2.6 → 2.7 → 3.x → 4.x), adjusting the boot plugin version, the dependency-management plugin, and the Java toolchain when a Boot line requires JDK 17 or 21. javax.* to jakarta.* package moves, Security filter chain rewrites, and property renames are applied from the guides. MyBatis and DGS starters often lag; when a compatible pair is unclear, the agent stops that component upgrade and lists it under human decisions rather than deleting GraphQL or MyBatis silently.

After each Boot line bump it runs ./gradlew test (and ./gradlew build when appropriate), fixing compilation and test failures caused by the framework change. SQLite and Flyway migrations under src/main/resources are exercised by repository tests; the clean task deletes ./dev.db, which the agent accounts for between runs. Spotless failures introduced by migrations are formatted rather than disabled.

The pull request names every guide step, every Gradle command with its outcome, Java version changes, and decisions left for a person (for example replacing DGS with another GraphQL stack, or moving off joda-time). No drive-by feature work lands in api controllers.

Codegen for GraphQL (com.netflix.dgs.codegen plugin 5.0.6 writing into package io.spring.graphql from src/main/resources/schema) is re-run after dependency bumps so generated sources match the schema. If codegen fails on a newer Boot line, that failure is recorded as a decision rather than deleting the schema graph.

## Start it with one API call

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

```json
{
  "agent": "codex",
  "input": "Upgrade this app from Spring Boot 2.6 to Spring Boot 4 following the official upgrade guide step by step. Run the tests after each step and fix what breaks. Open a pull request that lists each change and anything you left for a person to decide.",
  "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 pull request updates build.gradle (Boot plugin, dependency-management, Java compatibility and adjusted third-party starters) and the Java/Kotlin-free sources required for jakarta and Security changes. The description is a staged log toward Boot 4 with ./gradlew test results and an explicit decisions section for blockers such as DGS or MyBatis compatibility.

A reviewer verifies ./gradlew test on the branch, confirms the Java version matches what Boot 4 requires in the team’s environment, and resolves each listed decision before merge. Transcript and PR URL are on GET /o/{org}/sessions/{id}.

## Run it on every Spring Boot major release

When a new Spring Boot major ships, schedule one session per service still on the 2.6 line with this prompt and that service’s repository in resources. Long upgrades may need follow-up messages on the same execution_id rather than a second session.

Use webhook_url to alert owners when a run finishes with decisions left. Do not start another Boot major on the same repo until that PR merges or closes.

## Why run it on Rush?

Crossing three Boot majors needs a disposable JDK, Gradle wrapper downloads and repeated full test runs. The sandbox holds that toolchain and preserves every ./gradlew test log in the transcript.

Human decisions for GraphQL and MyBatis keep the PR honest instead of shipping a half-deleted API. Several services can move in parallel, each with its own proof.

## Frequently asked questions

### Can it jump directly from 2.6.3 to Boot 4 in one Gradle edit?

No. It follows the official guides in stages, running tests after each stage so failures stay attributable to a known Boot line.

### What happens if Netflix DGS has no Boot 4 starter yet?

The agent records that as a human decision, keeps the GraphQL module compiling on the newest Boot line that supports it when possible, and does not delete the schema under src/main/resources/schema without instruction.

### Does it upgrade Java as well?

Yes when a Boot target requires a newer JDK than sourceCompatibility 11. The PR states the new Java version and any toolchain block it adds to build.gradle.

### Is Maven supported for this job?

This fixture is Gradle-only (build.gradle, gradlew). On a Maven RealWorld app the agent would use ./mvnw test instead; it follows the build tool the repository already ships.