kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
community/contributors/devel/cherry-picks.md

4.0 KiB
Raw Blame History

Overview

This document explains how cherry-picks are managed on release branches within the kubernetes/kubernetes repository. A common use case for this task is backporting PRs from master to release branches.

Prerequisites

  • Contributor License Agreement is considered implicit for all code within cherry-pick pull requests, unless there is a large conflict.
  • A pull request merged against the master branch.
  • Release branch exists.
  • The normal git and GitHub configured shell environment for pushing to your kubernetes origin fork on GitHub and making a pull request against a configured remote upstream that tracks "https://github.com/kubernetes/kubernetes.git", including GITHUB_USER.
  • Have hub installed, which is most easily installed via go get github.com/github/hub assuming you have a standard golang development environment.

Initiate a Cherry-pick

  • Run the cherry-pick script. This example applies a master branch PR #98765 to the remote branch upstream/release-3.14: hack/cherry_pick_pull.sh upstream/release-3.14 98765

    • Be aware the cherry-pick script assumes you have a git remote called upstream that points at the Kubernetes github org. Please see our recommended Git workflow.
    • You will need to run the cherry-pick script separately for each patch release you want to cherry-pick to.

  • Your cherry-pick PR will immediately get the do-not-merge/cherry-pick-not-approved label. The Branch Manager will triage PRs targeted to the next .0 minor release branch up until the release, while the Patch Release Team will handle all cherry-picks to patch releases. Normal rules apply for code merge.

    • Reviewers /lgtm and owners /approve as they deem appropriate.
    • Milestones on cherry-pick PRs should be the milestone for the target release branch (for example, milestone 1.11 for a cherry-pick onto release-1.11).
    • You can find the current release team members in the appropriate release folder for the target release. You may cc them with <@githubusername> on your cherry-pick PR.

Cherry-pick Review

Cherry-pick pull requests have an additional requirement compared to normal pull requests. They must be approved specifically for cherry-pick by Approvers. The Branch Manager or the Patch Release Team are the final authority on removing the do-not-merge/cherry-pick-not-approved label and triggering a merge into the target branch.

Searching for Cherry-picks

Troubleshooting Cherry-picks

Contributors may encounter some of the following difficulties when initiating a cherry-pick.

  • A cherry-pick PR does not apply cleanly against an old release branch. In that case, you will need to manually fix conflicts.

  • The cherry-pick PR includes code that does not pass CI tests. In such a case you will have to fetch the auto-generated branch from your fork, amend the problematic commit and force push to the auto-generated branch. Alternatively, you can create a new PR, which is noisier.