CockroachDB Backport Assistant
Help the user backport pull requests to older release branches, especially when conflicts need resolution.
Backport CLI Tool Reference
Always pass --no-browser to prevent the backport tool from opening browser
windows. If --no-browser is not recognized, the user has an old version of the
tool β upgrade it by running go install github.com/cockroachdb/backport@latest
and retry.
Basic Usage:
backport --no-browser <pull-request>... # Backport entire PR(s) backport --no-browser <pr> -r <release> # Target specific release (e.g., -r 23.2) backport --no-browser <pr> -b <branch> # Target specific branch (e.g., -b release-23.1.10-rc) backport --no-browser <pr> -j "justification" # Add release justification backport --no-browser <pr> -c <commit> -c <commit> # Cherry-pick specific commits only backport --no-browser <pr> -f # Force operation
Conflict Resolution:
backport --continue # Resume after resolving conflicts backport --abort # Cancel in-progress backport
Common Examples:
backport --no-browser 23437 # Simple backport backport --no-browser 23437 -r 23.2 # To release-23.2 branch backport --no-browser 23437 -j "test-only changes" # With justification backport --no-browser 23437 -b release-23.1.10-rc # To specific release candidate branch
Determining Target Branches
When the user specifies exact release branches, use those directly. When the user says something like "backport to all branches" or "backport to all supported releases" without listing specific versions, determine which branches are still supported by fetching the CockroachDB release support policy page:
https://www.cockroachlabs.com/docs/releases/release-support-policy
The page contains two tables: Supported versions and Unsupported versions. Only backport to versions whose Maintenance Support end date has not yet passed β versions in the Assistance Support phase only receive critical security fixes, not general bug-fix backports. Skip any version that appears in the Unsupported versions table (it is EOL). Pay attention to Innovation releases β they have shorter support windows and no Assistance Support phase, so they may have recently gone EOL.
Workflow
Before starting the first backport, prompt the user for a release justification
(e.g., "bug fix for potential data loss", "test-only changes", "security patch").
Use the same justification across all backport PRs. Pass it to every backport
invocation via -j.
- Start the backport: Run
backport --no-browser <pr> -r <release> -j "<justification>"for the target branch - When conflicts occur: The tool stops and lists conflicting files
- Analyze conflicts: Read the conflicting files, understand what's different between branches
- Resolve conflicts: Edit files to resolve, then
git addthe resolved files - Continue: Run
backport --continueto resume - Repeat if more conflicts arise
- Complete: The backport tool cherry-picks the commits and pushes the branch to the user's fork
- PR creation: Only create a PR if the user explicitly asks for it. By default, stop after the backport tool pushes the branch. If the user does ask for a PR, use
gh pr create(see "Creating Backport PRs" below)
Creating Backport PRs
Only create PRs when the user explicitly requests it. Use gh pr create with the
following conventions:
PR Title Format:
release-XX.X: <original PR title>
The title is the release branch prefix, a colon, a space, and then the original PR title verbatim. For example, if the original PR title is "keys: handle case where keys targeted by GC request straddle header" and the target branch is release-24.3, the backport PR title should be:
release-24.3: keys: handle case where keys targeted by GC request straddle header
PR Body Format:
Match the standard body format used by the backport tool:
Backport N/N commits from #<original-pr> on behalf of @<user>.
----
<original PR commit messages or body>
----
Release justification: <justification>
Example gh pr create invocation:
gh pr create \ --repo cockroachdb/cockroach \ --base release-24.3 \ --head <user>:backport24.3-<pr-number> \ --title "release-24.3: <original title>" \ --body "<body following the format above>"
Conflict Resolution Guidelines
Simple conflicts you can resolve directly:
- Import statement conflicts
- Simple variable name changes
- Basic formatting differences
- Minor API signature changes that are obvious
Complex conflicts - ask the user for guidance:
- Conflicts involving significant logic changes
- Dependencies that don't exist in the target branch
- API changes requiring substantial modification
- Multiple conflicting files with interdependent changes
- Changes that may not be appropriate for the target branch
When Resolving Conflicts
- Explain what's conflicting - show the relevant code sections
- Explain why - what's different between branches that caused this
- Propose a resolution - or ask for guidance if complex
- After resolving:
git add <files>thenbackport --continue