代码拉取完成，页面将自动刷新
Contributions to Milvus are welcome from everyone. We strive to make the contribution process simple and straightforward. Up-to-date information can be found at milvus.io.
The following are a set of guidelines for contributing to Milvus. Following these guidelines makes contributing to this project easy and transparent. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
As for everything else in the project, the contributions to Milvus are governed by our Code of Conduct.
Content
| Suitable for | Projects | Resources |
|---|---|---|
| Go developers | milvus, milvus-sdk-go | |
| CPP developers | milvus, knowhere | |
| Developers interested in other languages | pymilvus, milvus-sdk-node, milvus-sdk-java | Contributing to PyMilvus |
| Kubernetes enthusiasts | milvus-helm | |
| Tech writers and docs enthusiasts | milvus-docs | Contributing to milvus docs |
| Web developers | milvus-insight |
If you encounter a bug, you can
If you're interested in existing issues, you can
question.bug, improvement, and enhancement by
If you require a new feature or major enhancement, you can
If you are a reviewer/approver of Milvus, you can
If you want to become a contributor of Milvus, submit your pull requests! For those just getting started, see GitHub workflow below.
All submissions will be reviewed as quickly as possible.
There will be a reviewer to review the codes, and an approver to review everything aside the codes, see code review for details.
If everything is perfect, the reviewer will label /lgtm, and the approver will label /approve.
Once the 2 labels are on your PR, and all actions pass, your PR will be merged into base branch automatically by our @sre-ci-robot
Generally, we follow the "fork-and-pull" Git workflow.
git clone git@github.com:<yourname>/milvus.git.git checkout -b my-topic-branch.git push origin my-topic-branch.
Remember to sync your forked repository before submitting proposed changes upstream. If you have an existing local repository, please update it before you start, to minimize the chance of merge conflicts.
git remote add upstream git@github.com:milvus-io/milvus.git
git fetch upstream
git checkout upstream/master -b my-topic-branch
Before submitting your pull requests for review, make sure that your changes are consistent with the coding style, and run unit tests to check your code coverage rate.
All contributions to this project must be accompanied by acknowledgment of, and agreement to, the Developer Certificate of Origin. Acknowledgment of and agreement to the Developer Certificate of Origin must be included in the comment section of each contribution and must take the form of Signed-off-by: {{Full Name}} <{{email address}}> (without the {}). Contributions without this acknowledgment will be required to add it before being accepted. If contributors are unable or unwilling to agree to the Developer Certificate of Origin, their contribution will not be included.
Contributors sign-off that they adhere to DCO by adding the following Signed-off-by line to commit messages:
This is my commit message
Signed-off-by: Random J Developer <random@developer.example.org>
Git also has a -s command line option to append this automatically to your commit message:
$ git commit -s -m 'This is my commit message'
Keeping a consistent style for code, code comments, commit messages, and PR descriptions will greatly accelerate your PR review process. We highly recommend you refer to and comply to the following style guides when you put together your pull requests:
We also use golangci-lint to perform code check. Run the following command before submitting your pull request and make sure there is no issue reported:
$ make static-check
To format code
$ make fmt
The C++ coding style used in Milvus generally follows Google C++ Style Guide. We made the following changes based on the guide:
Install clang-format
$ sudo apt-get install clang-format
Check code style
$ make cppcheck
Before submitting your Pull Request, make sure you have run unit test, and your code coverage rate is >= 90%.
You can run all the Golang unit tests using make.
$ make test-go
You can also run unit tests in package level.
# run unit tests in datanode package
$ go test ./internal/datanode -cover
ok github.com/milvus-io/milvus/internal/datanode 3.874s coverage: 88.2% of statements
You can run a sub unit test.
In this case, we are only concerned about the tests with name "SegmentReplica" and sub tests with name "segmentFlushed". When running sub tests, the coverage is not concerned.
$ go test ./internal/datanode -run SegmentReplica/segmentFlushed
ok github.com/milvus-io/milvus/internal/datanode 0.019s
It is recommended to use Mockery to generate mock implementations for unit test dependencies.
If your PR changes any interface definition, you shall run following commands to update all mockery implemented type before submitting it:
make generate-mockery
If your PR adds any new interface and related mockery types, please add a new entry under proper Makefile generate-mockery-xxx command.
generate-mockery-xxx: getdeps
# ...
# other mockery generation commands
# use mockery under $(INSTALL_PATH) to unify mockery binary version
$(INSTALL_PATH)/mockery --name=NewInterface ...
Install lcov
$ sudo apt-get install lcov
Run unit test and generate code for code coverage check
$ make codecov-cpp
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。