Shulou(Shulou.com)05/31 Report--

How to carry out cherry-pick analysis, I believe that many inexperienced people do not know what to do. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Although Kubernetes has many branches, the community mainly develops around the branch of master. Even if bug exists in other branches, it is usually repaired in the master branch before cherry-pick to the other branches.

Bug is inevitable in software development, so you often need to synchronize some patches from master to other branches that are still under maintenance. There are many ways to synchronize:

Manually submit PR to other branches

Automatically submit PR to other branches

In general, autocommit is more common, it automatically cherry-pick a master that has been incorporated into the PR to your designated branch, while manual submission is used only in rare cases.

Automatic cherry-pick

Using the hack/cherry_pick_pull.sh script in the Kubernetes repository, you can synchronize a PR merged into a master branch to another branch. It can help you automate all the processes of submitting PR.

prerequisite

You need to meet certain prerequisites to use hack/cherry_pick_pull.sh automatic synchronization:

You must have signed the CLA declaration, which is what every contributor must sign.

PR for master has been integrated

The Kubernetes repository has been fork in your Github account, and the fork repository has been clone in your local shell.

The remote warehouse that you must add to your warehouse is called upstream (by ordering git remote add upstream https://github.com/kubernetes/kubernetes.git)

Added export GITHUB_USER= to your environment variable

Hub command line tools have been installed

If you have been involved in code contributions, these requirements are generally automatically met, except for the last two.

The hub command line tool is an official tool provided by GitHub for manipulating GitHub from the command line. The need to add GITHUB_USER to the environment variable is precisely because the hub command-line tool is used. If you haven't already installed it, you can use the command go get github.com/github/hub to install it.

How to automatically cherry-pick

For example, you need to synchronize PR # 85444 on master to the branch release-1.17, and if you have all the previous conditions, you only need to use the following command:

Hack/cherry_pick_pull.sh upstream/release-1.17 85444

Note: this script will automatically create PR, do not try it easily, unless you really need to do so.

There will be a lot of information output during the execution of the script, so you can learn about the specific execution process:

[root@ecs-d8b6 kubernetes] # hack/cherry_pick_pull.sh upstream/release-1.17 85444mm + Updating remotes...Fetching upstreamremote: Enumerating objects: 34, done.remote: Counting objects: 100,100,100,100,100 (delta 34), done.remote: Total 48 (delta 34), reused 34 (delta 34), pack-reused 14Unpacking objects: 100,100 percent (48pm 48) Done.From https://github.com/kubernetes/kubernetes d87c921a516..1f913b45820 master-> upstream/master c0f31a4ef63..5c651b7bd5f release-1.16-> upstream/release-1.16 486425533b6..27babd49b95 release-1.17-> upstream/release-1.17 * [new tag] v1.17.0-rc.1-> v1.17.0-rc.1Fetching origin+++ Creating local branch automated-cherry-pick-of-#85444-upstream-release-1 .17-1574748271Branch 'automated-cherry-pick-of-#85444-upstream-release-1.17-1574748271' set up to track remote branch 'release-1.17' from' upstream'.Switched to a new branch 'automated-cherry-pick-of-#85444-upstream-release-1.17-1574748271 Downloading patch to / tmp/85444.patch (in case you need to do this again) + About to attempt cherry pick of PR. To reattempt: $git am- 3 / tmp/85444.patchApplying: Provided a mechanism to re-register hidden metrics.+++ I'm about to do the following to push to GitHub (and I'm assuming origin is your personal fork): git push origin automated-cherry-pick-of-#85444-upstream-release-1.17-1574748271 automatedkishi pickled of Mustang 854444Mube upstream Mustang 1.17 Proceed (anything but 'y' aborts the cherry-pick)? [done.Total] yEnumerating objects: 19, done.Counting objects: 100% (19 delta 19), done.Delta compression using up to 4 threadsCompressing objects: 100% (10 delta 10), done.Writing objects: 100% (10 done.Total 10), 2.19 KiB | 1.09 MiB/s, done.Total 10 (delta 8), reused 0 (delta 0) remote: Resolving deltas: 100% (8 done.Total 8) Completed with 8 local objects.remote: remote: Create a pull request for 'automated-cherry-pick-of-#85444-upstream-release-1.17' on GitHub by visiting:remote: https://github.com/RainbowMango/kubernetes/pull/new/automated-cherry-pick-of-%2385444-upstream-release-1.17remote: To https://github.com/RainbowMango/kubernetes.git * [new branch] automated-cherry-pick-of-#85444-upstream- Release-1.17-1574748271-> automated-cherry-pick-of-#85444-upstream-release-1.17+++ Creating a pull request on GitHub at RainbowMango:automated-cherry-pick-of-#85444-upstream-release-1.17 https://github.com/kubernetes/kubernetes/pull/85627+++ Returning you to the master branch and cleaning up.

In fact, the script actually simulates manual operations:

Create a local branch, such as automated-cherry-pick-of-#85444-upstream-release-1.17

Get commit information for PR through the hub tool (there may be multiple commit)

Transfer the relevant commit cherry-pick in the upstream/master to the local branch

Push the local branch to the remote (origin)

Submit a PR using the interface of GitHub

Manual cherry-pick

Manual cherry-pick generally does not occur frequently, because automatic cherry-pick is competent in most cases. Manual cherry-pick occurs only when conflicts are large and need to be handled manually.

Manual chery-pick needs to deal with conflicts, and the process of submitting a PR after processing is exactly the same as submitting it to master. I won't repeat it here.

The PR review process submitted to the release branch is slightly different from that submitted to the master branch, and the PR submitted to the release branch requires release manager approval in addition to release manager approval in the relevant domain.

The PR submitted to the release branch is automatically tagged with the do-not-merge/cherry-pick-not-approved tag, which is removed only after approval by the release manager, and then the CI incorporates the PR.

After reading the above, have you mastered the method of how to analyze cherry-pick? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.