As an open source project, K8s encourages active contributions from participants around the world, including Kubernetes/Kubernetes Master Project, Kubernetes/Website, Kubernetes/Enhancements and other K8S-related projects. This paper will introduce the PR related process and matters needing attention to K8s.

1. If you find a Bug, start with an Issue

First of all, congratulations, by carefully reading K8s source code (github.com/kubernetes/…) Or come across a K8s bug in your work practice, the first step should be official issues(github.com/kubernetes/…). Let’s check if other people have mentioned relevant or the same issue. If no relevant issue is found, you can click “New Issue “in the upper right corner of the page to create a New issue.

Then, select the corresponding issue type, or select the first “bug Report” if it is a bug:

Then, you need to fill in the title and content of the specific bug, which can be accurately filled according to the default template, such as What Happened, How to reproduce it, Environment(Kubectl version number, OS type), etc. Prepare the description as clearly as possible. Please directly mark the code file and line number corresponding to the bug so that Reviewer can quickly identify the authenticity of the issue.

2. Fork code for PR

The first step of PR(Pull Request) is to fork a copy of K8s master branch code into your own personal repository (Repo). Click “fork” in the upper right corner of GitHub interface and select your own personal GitHub account. Wait a few seconds to see the successful fork to its own repository.

Git clone the repo that has just been forked. The default branch is the master branch. Create a new branch based on the master branch. Then you can happily carry out code changes, add related comments, etc., modify the completion of git commit.

Note: Commit messages should be as clear as possible. Do not use the @xxx sign. Punctuation marks, etc. Specifications see: github.com/kubernetes/…

3. Submit the PR

After the personal branch is pushed to the remote GitHub repository, you can launch a “New pull Request “on the page and select the personal change branch. The target branch is Kubernetes/ Master. Click “Compare changes” to confirm the files and codes that need PR.

Git commit author must be consistent with CLA protocol (next step), otherwise cnCF-CLA: NO will be displayed on the label.

The next step is to fill in the relevant title and content of this PR. It is suggested to refer to the content template to fill in the relevant content items, select the corresponding SIG group, and complete the release-note mark. Otherwise, code review may be delayed due to incomplete necessary information.

K8s PR uses label to manage process and state change uniformly.

After THE PR is submitted, K8S-CI-Robot will automatically add corresponding labels, such as need-sig and need-triage, indicating that it needs to confirm which SIG(Special Interest Group) the PR belongs to and needs classification, etc. Then, we need to wait for relevant K8s members to conduct code review. If it is confirmed that the PR change is reasonable, we will make comments below, such as/SIG API-Machinery, / Triage accepted, etc. After receiving such comments, robot, It will automatically remove the needs-sig and needs-triage labels and add the corresponding labels in the comments.

4. Sign CLA agreement

CLA(Contributor License Agreement) is an Agreement that contributors must sign to participate in K8s PR. It is divided into personal edition and enterprise edition, and ordinary users can choose personal edition to sign.

If you have already signed a CLA agreement, all the items under the https://github.com/kubernetes/ project will be sharing agreement, namely as long as PR signed an agreement of CLA in either project, other projects is common.

If it is the first time to submit K8s PR, you will receive the agreement signing comment pushed by the robot, as follows:

At this point, you need according to link guide, signed an agreement to identity.linuxfoundation.org/ registered suggest that choose to Log in with making can direct access to making the username, Same as the previous step PR Git commit author. After filling in the relevant signing information as prompted, you will receive the formal signing success email as follows:

At this point, refresh the PR page or wait for a moment to check whether the label has changed to CNCF-CLA: yes, if you wait for several hours, you can manually comment: / check-clA, which will trigger the robot to re-verify the CLA signing status and update the label.

5. The Reviewer feedback

Once the PR is submitted, the robot will trigger label labeling, CLA validation, and Reviewer assignment. Each Reviewer will be assigned two by default, and each Reviewer will receive an email or Slack notification. Just wait for them to review the code changes.

At this point, other K8s members can also actively participate in this PR review, and you will see all Reviewers in the Reviewers in the upper right corner, including the two Reviewers assigned by default to the robot and other Reviewers who actively participated.

Reviewer may Comment directly on the code or write a Comment at the bottom, including some commands that can be recognized by the robot. All these are triggered by Comment, so we need to carefully review the Reviewer feedback.

6. Follow up Review

PR may not be merged smoothly in most cases, title/content description may not be detailed, code annotations may not be appropriate, etc. Reviewer may give a lot of review comments and suggestions, or relevant PR may have been proposed by others, or it may be rejected or rejected, etc. Don’t worry. The PR needs to be revised, refined, and submitted again based on feedback, with a comment @Reviewer PTAL to review again.

This is repeated until the PR is Merged or Closed. The time span may be as short as a few days, a week or even weeks or months. It is necessary to follow up and remind the review progress in time.

7. Code to Squash

Reviewer Reviewer (s) will check whether the git commit is squash if the code change is ok. If not, a Reviewer will comment to remind the Author to squash.

Due to the large number of K8s PR and the number of Git commit times corresponding to each PR may be large, Reviewer will generally remind code Squash before MERGE of K8s PR. Merge all the PR Git commits into one commit, so that after the code is merged into the main branch, the Git log can view only one Git commit record, greatly reducing the number of fragmented commit.

Git squash:

Git rebase -i HEAD~3 // Number indicates the number of Git commits to mergeCopy the code

In the interactive Editor, change pick to squash and save:

pick 2ebe926 Original commit
squash 31f33e9 Address feedback
pick b0315fe Second unit of work
Copy the code

You will see:

. Successfully rebased and updated refs/heads/xxxxCopy the code

Git push –force The local commit is forcibly pushed to a remote git squash. You can then remind the Reviewer again for confirmation.

8. I finally get to Approve

After Review & Squash above, WE finally got a Reviewer comment/LGTM, /approve. Congratulations, this PR Review has been approved. These comments will trigger robot merge code into the main branch. And mark Milestone such as V1.22 for the next release.

Before merging the PR code into the main branch, the robot performs various CI tests and checks to ensure that all checks are passed.

At this point, a PR merges into the main branch and changes its status from Open to Merged. The associated Issues will be automatically changed to Closed by the robot.

summary

As an open source project, K8s encourages participants around the world to contribute actively. This article introduces a complete process of K8s PR, including: Issue raising, code forking, PR submission, CLA signing, Review and Squash, etc. If everything goes well, PR can be merged into the main branch.

Master the above PR process, through active participation and contribution to K8s project, you can get the status change from Author, Contributor, Member, Chair and Lead, and make a contribution to K8s open source cause.

PS: Please pay attention to the public account “Straw Life” for more articles.