Correct inconsistent spacing and typos
This commit is contained in:
parent
7fb3a25176
commit
89de1fa321
@ -1,4 +1,4 @@
|
||||
# Contributing guidelines
|
||||
# Contributing Guidelines
|
||||
|
||||
## How to become a contributor and submit your own code
|
||||
|
||||
@ -21,6 +21,6 @@ Follow either of the two links above to access the appropriate CLA and instructi
|
||||
1. Fork the desired repo, develop and test your code changes.
|
||||
1. Submit a pull request.
|
||||
|
||||
### Adding dependencies
|
||||
### Adding Dependencies
|
||||
|
||||
If your patch depends on new packages, add those packages to [requirements.txt](requirements.txt) and [setup.py](setup.py).
|
||||
|
||||
@ -70,7 +70,6 @@ python -m examples.example1
|
||||
|
||||
(replace example1 with the example base filename)
|
||||
|
||||
|
||||
## Documentation
|
||||
|
||||
All APIs and Models' documentation can be found at the [Generated client's README file](kubernetes/README.md)
|
||||
@ -131,7 +130,6 @@ between client-python versions.
|
||||
| 9.0 | Kubernetes main repo, 1.13 branch | ✓ |
|
||||
| 10.0 Alpha/Beta | Kubernetes main repo, 1.14 branch | ✓ |
|
||||
|
||||
|
||||
Key:
|
||||
|
||||
* `✓` Changes in main Kubernetes repo are manually ([should be automated](https://github.com/kubernetes-client/python/issues/177)) published to client-python when they are available.
|
||||
@ -151,11 +149,10 @@ Participation in the Kubernetes community is governed by the [CNCF Code of Condu
|
||||
|
||||
## Kubernetes Incubator
|
||||
|
||||
This is a [Kubernetes Incubator project](https://github.com/kubernetes/community/blob/master/incubator.md).
|
||||
This is a [Kubernetes Incubator project](https://github.com/kubernetes/community/blob/master/incubator.md).
|
||||
|
||||
* [SIG: sig-api-machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)
|
||||
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### SSLError on macOS
|
||||
@ -179,10 +176,11 @@ You'll need a version with OpenSSL version 1.0.0 or later.
|
||||
|
||||
### Hostname doesn't match
|
||||
|
||||
If you get an `ssl.CertificateError` complaining about hostname match, your installed packages does not meet version [requirements](requirements.txt).
|
||||
If you get an `ssl.CertificateError` complaining about hostname match, your installed packages does not meet version [requirements](requirements.txt).
|
||||
Specifically check `ipaddress` and `urllib3` package versions to make sure they met requirements in [requirements.txt](requirements.txt) file.
|
||||
|
||||
### Why Exec/Attach calls doesn't work
|
||||
|
||||
Starting from 4.0 release, we do not support directly calling exec or attach calls. you should use stream module to call them. so instead
|
||||
of `resp = api.connect_get_namespaced_pod_exec(name, ...` you should call `resp = stream(api.connect_get_namespaced_pod_exec, name, ...`.
|
||||
See more at [exec example](examples/exec.py).
|
||||
|
||||
@ -1,20 +1,20 @@
|
||||
# Release process
|
||||
|
||||
Release process of python client involve creating (or updating) a release
|
||||
branch, update release tags, create distribution packages and upload them to
|
||||
pip.
|
||||
The release process of the python client involves creating (or updating) a release
|
||||
branch, updating release tags, and creating distribution packages and uploading them to
|
||||
pypi.
|
||||
|
||||
## Change logs
|
||||
Make sure changes logs are up to date [here](https://github.com/kubernetes-client/python/blob/master/CHANGELOG.md).
|
||||
If they are not, follow commits added after last release and update/commit
|
||||
Make sure the change logs are up to date [here](https://github.com/kubernetes-client/python/blob/master/CHANGELOG.md).
|
||||
If they are not, follow commits added after the last release and update/commit
|
||||
the change logs to master.
|
||||
|
||||
Then based on the release, follow one of next two steps.
|
||||
|
||||
## Update pre-release branch
|
||||
|
||||
Release branch name should have release-x.x format. All minor and pre-releases
|
||||
should be on the same branch. To update an existing branch with master(only for
|
||||
The release branch name should have release-x.x format. All minor and pre-releases
|
||||
should be on the same branch. To update an existing branch with master (only for
|
||||
latest pre-release):
|
||||
|
||||
```bash
|
||||
@ -37,8 +37,8 @@ cherry pick first:
|
||||
scripts/cherry_pick_pull.sh
|
||||
```
|
||||
|
||||
Do not merge master into an stable releast branch. Run the script without
|
||||
parameters and follow its instruction to create cherry pick PR and get the
|
||||
Do not merge master into a stable release branch. Run the script without
|
||||
parameters and follow its instructions to create a cherry pick PR. Get the
|
||||
PR merged then update your local branch:
|
||||
|
||||
```bash
|
||||
@ -49,8 +49,9 @@ git rebase upstream/$RELEASE_BRANCH
|
||||
```
|
||||
|
||||
## Sanity check generated client
|
||||
We need to make sure there is no API changes after running update client
|
||||
scripts. Such changes should be committed to master branch first. Run this
|
||||
|
||||
We need to make sure there are no API changes after running update client
|
||||
scripts. Such changes should be committed to the master branch first. Run this
|
||||
command:
|
||||
|
||||
```bash
|
||||
@ -58,17 +59,17 @@ scripts/update-client.sh
|
||||
```
|
||||
|
||||
And make sure there is no API change (version number changes should be fine
|
||||
as they will be updated in next step anyway). Do not commit any changes at
|
||||
this step and go back to master branch if there is any API changes.
|
||||
as they will be updated in the next step anyway). Do not commit any changes at
|
||||
this step and go back to the master branch if there are any API changes.
|
||||
|
||||
## Update release tags
|
||||
|
||||
Release tags are in scripts/constants.py file. These are the constants you may
|
||||
Release tags are in the "scripts/constants.py" file. These are the constants you may
|
||||
need to update:
|
||||
|
||||
CLIENT_VERSION: Client version should follow x.y.zDn where x,y,z are version
|
||||
numbers (integers) and D is one of "a" for alpha or "b" for beta and n is the
|
||||
pre-release number. For a final release, "Dn" part should be omitted. Examples:
|
||||
pre-release number. For a final release, the "Dn" part should be omitted. Examples:
|
||||
1.0.0a1, 2.0.1b2, 1.5.1.
|
||||
|
||||
DEVELOPMENT_STATUS: Update it to one of the values of "Development Status"
|
||||
@ -89,8 +90,9 @@ git push upstream $RELEASE_BRANCH
|
||||
```
|
||||
|
||||
## Make distribution packages
|
||||
|
||||
First make sure you are using a clean version of python. Use virtualenv and
|
||||
pyenv packages, make sure you are using python 2.7.12. I would normally do this
|
||||
pyenv packages. Make sure you are using python 2.7.12. I would normally do this
|
||||
on a clean machine:
|
||||
|
||||
(install [pyenv](https://github.com/yyuu/pyenv#installation))
|
||||
@ -128,9 +130,9 @@ python setup.py bdist_wheel --universal
|
||||
ls dist/
|
||||
```
|
||||
|
||||
You should see two files in dist folder. kubernetes\*.whl and kubernetes\*.tar.gz.
|
||||
You should see two files in dist folder: "kubernetes\*.whl" and "kubernetes\*.tar.gz".
|
||||
|
||||
TODO: We need a dry-run option an some way to test package upload process to pypi.
|
||||
TODO: We need a dry-run option and some way to test the package upload process to pypi.
|
||||
|
||||
If everything looks good, run this command to upload packages to pypi:
|
||||
|
||||
@ -142,13 +144,13 @@ twine upload dist/*
|
||||
|
||||
Create a gihub release by starting from
|
||||
[this page](https://github.com/kubernetes-client/python/releases).
|
||||
Click Deaft new release button. Name the tag the same as CLIENT_VERSION. Change
|
||||
Click the `Draft a new release button`. Name the tag the same as CLIENT_VERSION. Change
|
||||
the target branch to "release-x.y". If the release is a pre-release, check the
|
||||
`This is a pre-release` option.
|
||||
|
||||
|
||||
## Announcement
|
||||
Send an announcement email to kubernetes-dev@googlegroups.com with the subject [ANNOUNCE] kubernetes python-client $VERSION is released
|
||||
|
||||
Send an announcement email to kubernetes-dev@googlegroups.com with the subject: [ANNOUNCE] kubernetes python-client $VERSION is released
|
||||
|
||||
## Cleanup
|
||||
|
||||
@ -159,5 +161,4 @@ rm -rf .release
|
||||
|
||||
TODO: Convert steps in this document to an (semi-) automated script.
|
||||
|
||||
|
||||
ref: https://packaging.python.org/distributing/
|
||||
|
||||
@ -23,4 +23,3 @@ LIMIT 20
|
||||
More example queries can be found [here](https://gist.github.com/alex/4f100a9592b05e9b4d63)
|
||||
|
||||
Reference: https://mail.python.org/pipermail/distutils-sig/2016-May/028986.html
|
||||
|
||||
|
||||
@ -1,27 +1,29 @@
|
||||
# Submodules
|
||||
|
||||
To comply with [client library structure requirement](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/csi-client-structure-proposal.md),
|
||||
python client base utilities is moved into kubernetes-client/python-base repo. `git submodules` is being used to handle dependency to that repo.
|
||||
This document will provide basic steps to get submodules work.
|
||||
python client base utilities is moved into the [kubernetes-client/python-base](https://github.com/kubernetes-client/python-base) repo. `git submodules` is being used to handle dependency to that repo.
|
||||
This document will provide basic steps to get submodules working.
|
||||
|
||||
# Clone repo
|
||||
To clone repo, you need to pass `recursive` parameter to make the clone also get submodules:
|
||||
|
||||
To clone the repo, you need to pass the `recursive` parameter to make the clone also get submodules:
|
||||
|
||||
```bash
|
||||
git clone --recursive https://github.com/kubernetes-client/python.git
|
||||
```
|
||||
|
||||
if you already clone repo with no `--recursive` option, you can run this command to get submodules:
|
||||
if you have already cloned the repo with no `--recursive` option, you can run this command to get submodules:
|
||||
|
||||
```bash
|
||||
git submodule update --init
|
||||
```
|
||||
|
||||
# Update submodule
|
||||
If you changed kubernetes-client/python-base and want to pull your changes into this repo run this command:
|
||||
|
||||
If you changed [kubernetes-client/python-base](https://github.com/kubernetes-client/python-base) and want to pull your changes into this repo run this command:
|
||||
|
||||
```bash
|
||||
git submodule update --remote
|
||||
```
|
||||
|
||||
Once updated, you should create a new PR to commit changes to the repository.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user