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.