---
name: batch-deps-upgrade
description: Batch all open Dependabot dependency upgrade PRs into a single PR
disable-model-invocation: true
---

Batch all open Dependabot dependency upgrade PRs into a single PR for this repository.

## Step 1: Discover

Run: `gh pr list --repo XRPLF/xrpl4j --label dependencies --state open --limit 500 --json number,title,headRefName,body,url`

Parse each PR to extract coordinates and versions. Maven Dependabot PRs come in two formats:
- **Single-package PRs**: title is `Bump <groupId>:<artifactId> from <old> to <new>` — parse groupId, artifactId, old version, and new version from title
- **Property PRs**: title is `Bump <propertyName> from <old> to <new>` — the property name maps to a `<properties>` entry in `pom.xml` (e.g., `jackson.version`, `feign.version`)
- **Grouped PRs**: title lists multiple packages — parse from PR body, which contains a structured list of package updates

If any PR can't be parsed from either title or body, flag it for manual review. Build a table of all proposed upgrades. Report the table to the user before proceeding.

Also note: Dependabot sometimes opens duplicate PRs for the same dependency across submodules (e.g., `xrpl4j-core/org.assertj-assertj-core-3.27.7` and `xrpl4j-integration-tests/org.assertj-assertj-core-3.27.7`). Deduplicate — if the version is managed centrally in the root `pom.xml` `<dependencyManagement>` or `<properties>`, one update covers all submodules. Mark the duplicates as No-op (managed by root pom).

## Step 2: Apply

1. If a target branch already exists for this quarter's upgrades, work on that branch. Otherwise create a new branch from main: `deps/batch-deps-upgrade-YYYY-QN` (use current year and quarter).
2. Inspect the root `pom.xml` to determine where each dependency's version is controlled:
   - **Version property**: a `<properties>` entry like `<jackson.version>2.14.0</jackson.version>` — update the property value
   - **Direct version in `<dependencyManagement>`**: a `<version>` element — update it directly
   - **BOM import in `<dependencyManagement>`**: a `<dependency>` with `<type>pom</type><scope>import</scope>` — update its `<version>`
   - **Maven plugin version**: in `<build><pluginManagement><plugins>` — update the `<version>` element
3. Check for **compatibility constraints** before upgrading:
   - **Java version**: read `maven.compiler.source` from `pom.xml`. If a dependency's new version requires a higher Java version than the project's compiler source, mark it as Skipped immediately — do not attempt the upgrade. Known constraints: caffeine 3.x requires Java 11+, junit-bom 6.x requires Java 17+.
   - **API changes**: major version bumps may require source-level changes (e.g., changed APIs, removed methods, renamed classes). Flag these as needing extra validation.
4. Apply each upgrade by editing `pom.xml` directly. For version properties, use `mvn versions:set-property -Dproperty=<name> -DnewVersion=<version> -DprocessAllModules` as an alternative to manual XML edits — but verify the result looks correct before proceeding.
5. Run `mvn dependency:resolve -q` to verify the dependency graph resolves without conflicts after applying all changes.
6. Classify each Dependabot PR as:
   - **Upgraded**: version changed in pom.xml
   - **No-op**: version was already current or newer, or is a duplicate submodule PR covered by a root-pom change
   - **Skipped**: compatibility issue or unresolvable conflict

## Step 3: Validate

Run the build and test suite in order:

1. `mvn clean install`
   - This compiles all modules, runs checkstyle, runs unit tests, and runs integration tests
2. If step 1 fails, **attempt to fix the breaking change with code modifications before rolling back**. Common patterns for Java/Maven:
   - **Removed or renamed API** (e.g., a method removed in a major version): update call sites to use the new API
   - **Changed constructor or builder pattern**: adapt usage to the new API
   - **Checkstyle violations from new code patterns**: fix the style issue
   - **Compile errors from changed generics or type parameters**: adjust the type annotations
   - **Breaking changes in BouncyCastle** (crypto library): the API often changes significantly between major versions — check migration notes
   - **JUnit 5 → 6 migration**: junit-bom 6.x requires Java 17+ (class file version 61.0) — skip unless the project has already raised its minimum Java version to 17
3. Only roll back and mark as Skipped if:
   - The fix requires a large-scale migration across many files
   - The upgrade is blocked by an incompatible transitive dependency you cannot resolve
4. If a failure persists after investigation, roll back the upgrade and mark it as Skipped. Re-run validation until green.

## Step 4: Generate Outputs

Do NOT commit or create a PR. Instead, generate the following outputs for the human to use:

1. **Code changes note** — write a markdown file (`.claude/skills/batch-deps-upgrade/code-changes.md`) documenting every non-pom.xml source code change: what broke, why, and the minimal fix applied.

2. **Commit message** — output a concise commit message the human can copy-paste. Format: `chore(deps): quarterly batch dependency upgrade YYYY-QN` followed by a brief summary of upgrades, skips, and no-ops.

3. **PR description** — write a markdown file (`.claude/skills/batch-deps-upgrade/pr-description.md`) containing:
   - A summary section describing the batch upgrade
   - A "Superseded Dependabot PRs" table with columns: PR (linked), Package (`groupId:artifactId`), From, To, Status, MajorVersionUpgrade
     - Status values: Upgraded, No-op (reason), Skipped (reason: compatibility issue / build failure: error)
     - MajorVersionUpgrade: `No` if the major version number did not change. Otherwise `Yes` plus a link for each major version crossed — link to the package's Maven Central release notes, GitHub releases page, or CHANGELOG.md. Verify each link returns HTTP 200 before including it.
   - Closing instructions with two paragraphs:
     1. "After merging, close the following superseded PRs (Skipped ones remain open for future handling): #X, #Y, #Z" — list only Upgraded and No-op PRs.
     2. "The following PRs were Skipped and should remain open: #A (`groupId:artifactId`), #B (`groupId:artifactId`), ..." — these stay open so Dependabot keeps rebasing them.