Verify that the backport PR does not add a cluster version nor a version gate. Ask on #engineering if you need details about why backports must never add cluster versions or version gates.
Check the release notes in the commit messages, to ensure they are applicable to the branch (if a release note refers to another change / PR that is not being backported, or that may be backported later, suggest a rephrasing.)
Blathers will automatically backport PRs with backport tags
Upon merge, Blathers will automatically attempt to create backport PRs for each branch that was indicated via a backport label on your PR.
If any of the backport PRs fail, Blathers will post a comment on the original PR with details.
Automatic backport can fail for a few reasons, such as:
backport branch already exists for a PR
backport has merge conflicts
backport branch contains merge commits, which are not allowed in backports
If this happens, you must use the manual method (the backport command-line tool) described below.
Blathers can be instructed to try to backport a PR with a comment
You can ask Blathers to create a backport PR without using the tagging system and waiting for merge by commenting on a PR, with the following syntax:
blathers backport <branch1> <branch2> â¦
For example, to backport a PR to 21.1 and 20.2, you would add a comment on the PR that says:
blathers backport 21.1 20.2
Blathers will then immediately carry out the backports just as it would when it detects a merged PR with backport tags.
Manual Method with the backport CLI tool
If Blathers was unable to automatically create a backport PR, follow these steps after the main PR is merged to cherry-pick it into the release branch.
Make sure theÂ backport tool is installed:Â go get github.com/benesch/backport
For first time setup, you will need to set the cockroach.remote git config option. If your fork of cockroach is in the remote named origin, then set it with git config cockroach.remote origin while in your local cockroach git repo.
RunÂ backport -r VV.V xxxxx, where VV.V is replaced by the version number of the release branch and xxxxx is replaced by the GitHub PR number of the PR you are trying to backport, or a space-separated list of PR numbers. This will automatically create a backport branch and upload it to your repository against the release branch to GitHub. Then, it will try to open your browser to create a new PR with that branch, or provide instruction on how to do this manually if it cannot open your browser.
If there were merge conflicts,Â backport will halt and ask you to fix them. Once they're fixed, runÂ backport --continue to continue the procedure.
If there were any non-trivial merge conflicts, be sure to call those out in the PR message so reviewers can pay closer attention to the diff.
If something goes wrong, you can use backport --abort to give up on the current manual backport.
Note: You do not need to use bors to merge a backport PR; just hit the big green button once the CI is green and the backport is approved by the reviewer (usually the main reviewer of the original PR to master branch).