Apply Renovate Prs

Apply Renovate PRs Locally

Collect every open pull request raised by Renovate in the target GitHub repository and apply their changes to the local working tree, so all dependency upgrades can be built and tested together.

Hard constraints

• Never run git commit, git push, git merge, git cherry-pick, git rebase, gh pr merge, gh pr close, or gh pr review.
• Do not create branches, tags, or worktrees unless the user asks.
• Do not modify anything on GitHub. Read-only gh commands only (gh pr list, gh pr view, gh pr diff, gh api GET).
• Leave the result as uncommitted changes in the working tree and report what was applied, so the user decides what to do next.

1. Check preconditions

gh auth status
git rev-parse --show-toplevel
git status --short --branch

• If gh is missing or unauthenticated, stop and tell the user.
• If the working tree already has uncommitted changes, report them and ask whether to continue on top of them or let the user stash first. Do not stash or discard the user's work on your own.
• Record the current branch and git rev-parse HEAD in the final report, so the user can undo with git checkout -- . / git stash.
• Fetch the base branch objects so three-way applies have the pre-image blobs:

git fetch origin

Determine the repository: use the origin remote of the current directory by default, or the owner/repo the user names (pass it as -R owner/repo to every gh command).

2. Discover the open Renovate PRs

gh pr list --app renovate --state open --limit 100 \
  --json number,title,headRefName,isDraft,mergeable,files,labels,url

If that returns nothing, Renovate may be running as a user account or a self-hosted app, so fall back to:

gh pr list --state open --limit 100 \
  --json number,title,headRefName,author,isDraft,url \
  --jq '[.[] | select((.author.login | test("renovate"; "i")) or (.headRefName | startswith("renovate/")))]'

Notes:

• Renovate's "Dependency Dashboard" is a GitHub issue, not a PR. Ignore it.
• Exclude draft PRs by default and say so; include them only if the user asks.
• If the user restricted the scope (for example "only patch updates", "only the Spring Boot ones"), filter accordingly and state the applied filter.

Show the list to the user before applying, then proceed.

3. Order the PRs

Apply in an order that minimises conflicts:

1. Patch updates, then minor, then major (major upgrades are most likely to need follow-up source changes).
2. Manifest-only PRs before lockfile-heavy PRs.
3. Grouped PRs (Renovate branches such as renovate/all-minor-patch) before the single-dependency PRs they may overlap with.

Read each version bump from the PR title (Renovate titles are of the form chore(deps): update dependency org.foo:bar to v1.2.3) and keep a running table of PR number → package → old version → new version.

4. Apply each PR

For every PR, take the patch and apply it with a three-way merge:

gh pr diff <number> --patch > /tmp/renovate-<number>.patch
git apply --3way --whitespace=nowarn /tmp/renovate-<number>.patch

Then unstage what --3way staged, keeping the file contents, so the review diff stays readable:

git reset --quiet

Skip the git reset if the user chose to continue on top of pre-existing staged changes — it would unstage those too. In that case, note in the report that the applied changes are staged.

Handle the outcomes:

• Clean apply: record it as applied and continue.
• Conflict markers (git apply --3way writes <<<<<<< into the file): resolve them by hand. For dependency files the resolution is almost always "keep both bumps" — take the higher version for each distinct dependency, and never leave a marker behind. Verify with git grep -n '^<<<<<<<\|^>>>>>>>'.
• Patch fails to apply at all (error: patch does not apply): do not force it. Instead read the PR diff (gh pr diff <number>) and make the equivalent edit directly in the manifest — change the version coordinate to the target version from the PR title. This is the reliable path for generated lockfiles and for PRs whose base is stale.
• Lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, gradle.lockfile, uv.lock, poetry.lock, go.sum, …): applied lockfile hunks from several PRs are frequently inconsistent. Prefer applying only the manifest changes and regenerating each lockfile once, in step 6.

Also apply Renovate PRs that touch non-code manifests — Dockerfile, docker-compose.yml, .github/workflows/*.yml, .tool-versions, .sdkmanrc, renovate.json — the same way.

After applying a wrapper or Docker image PR, work through the matching entry in step 5 before moving on.

5. Special cases

Renovate only updates the files its managers know about. Some repositories duplicate the same version elsewhere, so after applying a PR check for these companion edits and make them by hand.

Maven / Gradle wrapper PRs — also update .sdkmanrc

Renovate updates .mvn/wrapper/maven-wrapper.properties or gradle/wrapper/gradle-wrapper.properties, but it does not update .sdkmanrc, so the SDKMAN-pinned build tool stays behind.

grep -n distributionUrl .mvn/wrapper/maven-wrapper.properties \
  gradle/wrapper/gradle-wrapper.properties 2>/dev/null
cat .sdkmanrc 2>/dev/null

• Read the new version from distributionUrl (apache-maven-3.9.11-bin.zip → 3.9.11, gradle-9.1.0-bin.zip → 9.1.0) and set the matching maven= / gradle= line in .sdkmanrc to it.
• Change only the candidate the PR bumped. Leave java= alone unless a PR actually changed the project's Java version.
• Keep the SDKMAN version identifier format (e.g. java=25-tem, not a bare 25). If unsure the exact version is published, check sdk list maven / sdk list gradle; if it is not available yet, leave .sdkmanrc untouched and report it.
• Wrapper PRs also carry binary hunks (gradle-wrapper.jar). gh pr diff --patch includes those, but if git apply rejects the binary hunk, take the file from the PR head instead:

git fetch origin pull/<number>/head
git checkout FETCH_HEAD -- gradle/wrapper/gradle-wrapper.jar
git reset --quiet

If the repository has no .sdkmanrc, do not create one.

Docker image version PRs — also update TestcontainersConfig

Renovate bumps image tags in Dockerfile, compose.yaml/docker-compose.yml and Kubernetes manifests, but image tags hardcoded in Java/Kotlin test configuration are invisible to it. Update the shared Testcontainers configuration class to the same tags.

git grep -ln "TestcontainersConfig" -- '*.java' '*.kt'
# root module and, for multi-module builds, every nested module
git grep -nE '"[a-z0-9][a-z0-9._/-]*:[a-zA-Z0-9][a-zA-Z0-9._-]*"' -- \
  'src/test/**/*.java' 'src/test/**/*.kt' \
  '**/src/test/**/*.java' '**/src/test/**/*.kt'

Typical declarations to update:

static GenericContainer<?> mailhog = new GenericContainer<>("mailhog/mailhog:v1.0.1");
PostgreSQLContainer postgres = new PostgreSQLContainer("postgres:18-alpine");
GenericContainer<?> redis = new GenericContainer<>(DockerImageName.parse("redis:7-alpine"));

Rules:

• Match on the image name, not the tag: only update a literal whose repository part is the image the PR bumped.
• Preserve the tag flavour. If the class pins postgres:18-alpine and the PR moves compose to postgres:19, write postgres:19-alpine — do not drop the -alpine/-jammy/-slim suffix or invent one the registry lacks.
• Change only the version literal. Keep surrounding calls such as DockerImageName.parse(...).asCompatibleSubstituteFor(...), withExposedPorts(...), and withDatabaseName(...) exactly as they are.
• If the tag comes from a constant, an enum, libs.versions.toml, a DockerImages-style holder, or a test property, update it at that single source instead of at each usage.
• Check the other places test images hide: abstract base test classes, *IT/*Tests classes with their own GenericContainer, src/test/resources/** compose files, application-test.properties, and testcontainers.properties.
• Never bump an image in test configuration that no Renovate PR bumped.

These edits are only validated by running the tests, so make sure step 7 runs the integration tests, not just compilation.

If the repository would benefit from Renovate tracking these files directly, mention a customManagers regex manager as a follow-up suggestion in the report — do not edit renovate.json unless the user asks.

6. Regenerate derived files once

After all PRs are applied, regenerate lockfiles/derived files a single time using the project's own tooling. Pick the commands that match the repository:

Use the wrapper scripts (./mvnw, ./gradlew) when present. If a command needs network access that is unavailable, say so instead of hand-editing a lockfile.

7. Verify the combined upgrade

Run the project's build and tests, preferring an existing task runner (Taskfile.yml, Makefile, package.json scripts):

./mvnw verify        # or ./gradlew build, npm test, task test, ...

If the build breaks:

• Identify which upgrade caused it (a major bump is the usual suspect).
• Read that PR's release notes section — gh pr view <number> renders the body Renovate writes, including breaking changes.
• Make the minimal source changes needed for the new API, or, if the fix is large or ambiguous, revert just that one PR's files (git checkout -- <paths> for files only that PR touched) and report it as skipped with the reason.

Never make a test pass by weakening or deleting an assertion.

8. Report

Finish with a summary that contains:

• The repository, base branch, and starting commit SHA.
• A table of every Renovate PR considered: number, title, and outcome (applied, applied with manual resolution, applied manually, skipped).
• For skipped PRs, the concrete reason.
• The companion edits from step 5 (.sdkmanrc, TestcontainersConfig, other hardcoded image tags), and any that were needed but could not be made.
• The regeneration and verification commands run, and their real results — report failures with the relevant output rather than glossing over them.
• The list of changed files (git status --short).
• A reminder that nothing was committed or pushed, plus how to review and undo:

git diff                 # review everything applied
git checkout -- .        # discard all applied changes