TiDB Operator is written in Go. If you don't have a Go development environment, set one up.
The version of Go should be 1.9 or later.
After Go is installed, you need to define GOPATH
and modify PATH
modified to access your Go binaries.
You can configure them as follows, or you can Google a setup as you like.
$ export GOPATH=$HOME/go
$ export PATH=$PATH:$GOPATH/bin
TiDB Operator uses retool to manage Go related tools.
$ go get -u github.com/twitchtv/retool
- visit https://github.com/pingcap/tidb-operator
- Click
Fork
button (top right) to establish a cloud-based fork.
Per Go's workspace instructions, place TiDB Operator code on your
GOPATH
using the following cloning procedure.
Define a local working directory:
$ working_dir=$GOPATH/src/github.com/pingcap
Set user
to match your github profile name:
$ user={your github profile name}
Create your clone:
$ mkdir -p $working_dir
$ cd $working_dir
$ git clone git@github.com:$user/tidb-operator.git
Set your clone to track upstream repository.
$ cd $working_dir/tidb-operator
$ git remote add upstream https://github.com/pingcap/tidb-operator
Since you don't have write access to the upstream repository, you need to disable pushing to upstream master:
$ git remote set-url --push upstream no_push
$ git remote -v
The output should look like:
origin git@github.com:$(user)/tidb-operator.git (fetch)
origin git@github.com:$(user)/tidb-operator.git (push)
upstream https://github.com/pingcap/tidb-operator (fetch)
upstream no_push (push)
Get your local master up to date:
$ cd $working_dir/tidb-operator
$ git fetch upstream
$ git checkout master
$ git rebase upstream/master
Branch from master:
$ git checkout -b myfeature
You can now edit the code on the myfeature
branch.
Before running your code in a real Kubernetes cluster, make sure it passes all unit tests.
$ make test
First you should build a local Kubernetes environment for e2e tests, so we provide the following two ways to build Kubernetes cluster: dind and kind. Both of them are available, but we recommend using kind, because it is easier to use and more stable
-
Use dind to build Kubernetes cluster
Follow this guide to spin up a local DinD Kubernetes cluster.
-
Use kind to build Kubernetes cluster
Please ensure you have install kind and it's version == v0.4.0
Use the following command to create a local kind Kubernetes environment.
$ ./hack/kind-cluster-build.sh
If you have customization requirements, please refer the help info:
$ ./hack/kind-cluster-build.sh --help
Setting
KUBECONFIG
environment variable before using the Kubernetes cluster:export KUBECONFIG=$(kind get kubeconfig-path --name=<clusterName>)
Then you can build and push Docker images to the inner Docker registry. The inner Docker registry is available as localhost:5000
both on the host machine and inside the Kubernetes cluster.
$ make docker-push
$ make e2e-docker-push
After Docker images are pushed to the inner Docker registry, run e2e tests:
$ kubectl apply -f tests/manifests/e2e/e2e.yaml
You can get the e2e test report from the log of testing pod:
$ kubectl -n=tidb-operator-e2e logs -f tidb-operator-e2e
To re-run e2e tests, delete the testing pod and apply it again.
While on your myfeature
branch, run the following commands:
$ git fetch upstream
$ git rebase upstream/master
Before you commit, make sure that all the checks and unit tests are passed:
$ make check
$ make test
Then commit your changes.
$ git commit
Likely you'll go back and edit/build/test some more than commit --amend
in a few cycles.
When your commit is ready for review (or just to establish an offsite backup of your work),
push your branch to your fork on github.com
:
$ git push -f origin myfeature
- Visit your fork at https://github.com/$user/tidb-operator (replace
$user
obviously). - Click the
Compare & pull request
button next to yourmyfeature
branch.
Once your pull request has been opened, it will be assigned to at least two reviewers. Those reviewers will do a thorough code review, looking for correctness, bugs, opportunities for improvement, documentation and comments, and style.
Commit changes made in response to review comments to the same branch on your fork.
Very small PRs are easy to review. Very large PRs are very difficult to review.