We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles.
Please fill out either the individual or corporate Contributor License Agreement (CLA).
Follow either of the two links above to access the appropriate CLA and instructions for how to sign and return it. Once we receive it, we'll be able to accept your pull requests.
The Kubernetes Python client consists of this main repository (repo) and the base repo, the python-base repository. The main repository contains mostly files that are generated by the OpenAPI generator from this OpenAPI spec. The base repo is the utility part of the python client and allows developers to create their own kubernetes clients. The base repo is a submodule of the main repo.
The following folders are automatically generated. You will need to submit a patch to the upstream Kubernetes repo kubernetes or the OpenAPI generator repo openapi-generator.
In this main repo, the following folders contain developer written codes and the patches should be submitted as pull requests here:
The following folders and symbolic links in this main repo are in fact from the base repo. The base repo contains developer written codes only. The patches should be sent to the base repo instead:
If your patch depends on new packages, add those packages to requirements.txt and/or setup.py. If these package are for testing only, add those to test-requirements.txt.
Generally we would like to see one commit per pull request. However, if the pull request is reasonably large, the PR can be divided into several commits that make logical sense. The commit message should be clear and indicative of the aim of the fix. Sometimes multiple commits in a single pull request is acceptable if it meets the Kubernetes pull request guidelines.
If you have several commits in a pull request and have been asked to squash your commits, please use git reset --soft HEAD~N_COMMITS
and commit again to make your PR a single commit.
The symbolic links contained in this repo do not work for Windows operating systems. If you are a Windows developer, please run the fix inside the scripts folder or manually copy the content of the kubernetes/base folder into the kubernetes folder.
In addition to running the fix yourself and telling us that your fix works, you can demonstrate that your fix really works by using unit tests and end to end tests. Tests are mainly located in three places. You should put your tests into the places that they fit in.
test_*.py
: These tests use the package Mock
and confirms the functionality of the base repo files.We use an automatic coding style checker by using the diff
of the autopep8 output and your code file. To make sure that your code passes the coding style checker, run autopep8 --in-place --aggressive --aggressive your_code.py
before committing and submitting.
If you write a new end to end (e2e) test, or change behaviors that affect e2e tests, you should set up a local cluster and test them on your machine. The following steps will help you run the unit tests.
Acquire a local cluster. Minikube is a good choice for Windows and Linux developers. Alternatively if you are on Linux, you can clone the kubernetes repo and run install-etcd.sh and then local-up-cluster.sh to get a local cluster up and running.
Run the unit tests. In the root directory of the main repo, run python -m unittest discover
.
Check the test results and make corresponding fixes.
Your contribution to the base repo will not be automatically reflected in the main repo after your PR is merged. Instead, please update the base
submodule in your fork of the main repo as follows:
$ git submodule update --remote
You may now add a release note to CHANGELOG.md if needed and then commit and push to your fork. You can now send a PR to this main repo to complete your contribution.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。