Contribution Guidelines
Contribute to Rainbond
Rainbond is a cloud-native application management platform that is easy to use and does not require knowledge of containers, Kubernetes and the underlying complex technologies. It supports managing multiple Kubernetes clusters and managing the entire lifecycle of enterprise applications.The main functions include application development environment, application market, microservice architecture, application delivery, application operation and maintenance, application-level multi-cloud management, etc.
If you're interested in contributing to Rainbond, hopefully this documentation will make your contribution process easier, faster, and more efficient.
If you're new to open source contributing, check out the Open Source Guides website, which provides some open source contributing guides, a collection of resources for people, communities, and companies who want to learn how to contribute to open source projects.
CODE_OF_CONDUCT
Rainbond expects project participants to abide by the Code of Conduct, please read CODE_OF_CONDUCT.
participate
There are many ways to contribute to:, not just code contributions0
- Deal with unresolved issuesand put forward your solution ideas.
- Feedback bugs.When you find a bug, please use issues to report and discuss.
- Propose new features.When you want to propose a new feature, please use issues to report and discuss.
- code contribution
- Documentation Contribution
- Contribute open source applicationsto Rainbond App Store
- Contribute open source pluginsto the Rainbond app store
Contributions are very welcome. If you think your contribution needs help, please addsmall assistants to WeChatto contact us, and Rainbond TOC members will help you continue to contribute.
Git Commit Specification
We refer to Angular Specification, and try to provide clearer historical information to facilitate the judgment of the purpose of submission and browsing.Each commit message contains a header, body and footer.The header has a special format with type, scope and subject:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
There should be a blank line between header, body, and footer. The header is required, and the scope is optional.The text of each line of the commit message cannot exceed 72 characters.This makes it easier to read on github and git tools.
Type
type is used to describe the category of commit, it must be one of the following types:
- feat: new features
- fix: fix bug
- docs: just documentation changes
- style: changes that do not affect the meaning of the code (e.g. spaces, formatting, missing semicolons)
- refactor: a code change that neither fixes a bug nor adds a new feature
- perf: code changes to improve performance
- test: add or fix tests
- chore: changes to builds or auxiliary tools, such as generating documentation
- ci: Modifications to CI configurations or scripts, such as Github Actions
- revert: roll back a commit
Scope (optional)
scope is used to describe the scope of the impact of the commit. When there are multiple scopes, you can use * or leave it blank.The scope is optional, it can provide additional contextual information to the type and is enclosed in parentheses, and it can be something that specifies where to commit changes.It can also be a link to fix an issue on Github.For example,:fix(worker), fix(#123), etc.
Subject
subject is used for a concise description of commit:
- Use imperative sentences, usually starting with the original form of the verb, e.g. use change instead of changed or changes
- first letter lowercase
- Do not add a period (.) at the end
Example
feat: add code audit function
fix(api): wrong number of running apps
style: add couple of missing semi colons
Tools for writing qualified Commit messages
Commitizen is a tool for writing qualified Commit messages.
Install
npm install -g commitizen
npm install -g cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
use
git add
git cz
Next, select the corresponding scope of influence and enter the commit message.
Pull Request Specification
When we accept a Pull Request, all commits are squashed into one.So the title of the Pull Request will be the subject line of the commit message.So we hope that the title of the Pull Request can also provide more accurate information.Make sure that the title of the Pull Request uses the same format as the subject line in the commit message.If this format is not followed, the CI check will fail.
Contributing to Rainbond will get you:
The GitHub README will showcase your contributions and list your Github avatar and Github username.
Contributor certificate issued by the Rainbond community