First, thank you for contributing to KubeBlocks! This document provides the guidelines for how to contribute to KubeBlocks.
Contributing to KubeBlocks through issues and pull-requests, make sure you are familiar with Github and the pull request workflow.
To submit a proposed change, read the following workflow.
- Before you create a new issue, please do a search in open issues to see if the issue or feature request has already been filed.
- If you find your issue already exists, make relevant comments or add your reaction.
- If you can not find you issue exists, choose the specific issue type and open a new issue.
Currently, there are 4 types of issues:
- Bug report: You’ve found a bug with the code, and want to report or track the bug. Show more details, let us know about an unexpected error, a crash, or an incorrect behavior.
- Feature request: Suggest a new feature. This allows feedback from others before code is written.
- Document request: Contribute to the KubeBlocks documentation.
- Report a security vulnerability: Review our security policy first and then report a vulnerability.
- Fork the KubeBlocks repository to your Github account, create a new branch and clone to your host.
- Branch naming style should match the pattern:
feature/|bugfix/|release/|hotfix/|support/|dependabot/
. KubeBlocks performs a pull request check to verify the pull request branch name.
- Branch naming style should match the pattern:
- See the Developing KubeBlocks docs for more information about setting up a KubeBlocks development environment.
- Make your changes.
- Update relevant documentation for the change.
- Make sure all tests and checks are passed.
cd kubeblocks make reviewable
Submit the branch as a pull request to the main KubeBlocks repository.
The pull request title must follow the format outlined in the conventional commits spec. Because KubeBlocks squashes commits before merging branches, this means that only the pull request title must conform to this format. KubeBlocks performs a pull request check to verify the pull request title in case you forget.
The following are all good examples of pull request titles:
feat(apps): add foo bar baz feature
fix(kbcli): fix foo bar baz bug
chore: tidy up Makefile
docs: fix typos
Wait for the CI process to finish and make sure all checks are green.
All pull requests should be reviewed, a pull request need at least approved by two maintainers before merging.
All pull requests are squashed and merged, after code review finished, the pull request will be merged into the main branch.
TODO: add DCO
(The Developer Certificate of Origin) or CLA
(Contributor License Agreement)