We recommend that whether it is a bug feedback or a fix, an issue is first created to describe the bug in detail, so that the community can find and review the problem and code through the issue record. Bug feedback Issues usually need to include complete description of the bug information and reproducible scenarios so that the community can quickly locate the cause of the bug and fix it. All open issues that contain the #bug
tag need to be fixed.
In the communication process, a detailed description, mechanisms and usage scenarios of the new function (or refactoring) can promote it to be implemented better and faster (including test cases and codes, and CI/CD related work). If you plan to implement a major feature (or refactoring), be sure to communicate with the core development team through Issue or other means so that everyone can promote it in the most efficient way. Issues opened with the label of #feature
are all new features that need to be implemented, and issues opened with the label of #enhancement
are all features that need to be improved and refactored.
Helping answering the questions in the Linkis community is a very valuable way to contribute; there will always be new users in the community that will keep coming in. While helping new users, you can also show your expertise.
You can find linkis documentations at linkis-Website, and the supplement of the document is also crucial to the development of Linkis.
Including participating in and helping to organize community exchanges, community operation activities, etc., and other activities that can help the Linkis project and the community.
There are many branches,including temporary branches,in Linkis repository,but only three of them matter:
Original warehouse: https://github.com/apache/linkis The apache warehouse of linkis is called the original warehouse in the text
Fork library: From https://github.com/apache/linkis fork to your own personal repository to become a fork library
Scene: There is a new branch in the original warehouse, but the forked library does not have this branch (you can choose to delete and re-fork, but the changes that have not been merged to the original warehouse will be lost)
Operate in your own clone's local project
git remote add apache git@github.com:apache/linkis.git
git fetch apache
git checkout -b dev-1.1.4 apache/dev-1.1.4
git push origin dev-1.1.4:dev-1.1.4
git remote remove apache
git pull
Confirm the base branch of the current development (usually the current version in progress, such as version 1.1.0 currently under development by the community, then the branch is dev-1.1.0, if you are not sure, you can ask in the community group or in @relevant classmates in the issue)
Synchronize the latest code of the original warehouse branch to its own fork warehouse branch , See the guideline Synchronize the new branch of the original repository to your own fork repository
Based on the development branch, pull the new fix/feature branch (do not modify it directly on the original branch, if the subsequent PR is merged in the squash method, the submitted commit records will be merged into one)
git checkout -b dev-1.1.4-fix dev-1.1.4 git push origin dev-1.1.4-fix:dev-1.1.4-fix
[WIP] Dev 1.1.1 Add junit test code for [linkis-common]
; associate the corresponding issue, etc.)git branch -d dev-1.1.4-fix git push
Please note: The dev branch of major features will be named with corresponding naming instructions in addition to the version number, such as: dev-0.10.0-flink, which refers to the flink feature development branch of 0.10.0.
Linkis front-end and back-end code share the same code base, but they are separated in development. Before starting the development, please fork the Linkis project to your Github Repositories. When developing, please develop based on the Linkis code base in your Github Repositories.
We recommend to clone the dev branch and name it dev-fix for development. At the same time, create a new dev-fix branch in your own warehouse and modify it directly on the original branch. If the subsequent PR is merged in the squash method, the submitted commit records will be merged into one
//pull the branch git clone https://github.com/{githubid}/linkis.git --branch dev //Generate local dev-fix branch according to dev git checkout -b dev-fix dev //Push the local dev-fix branch to your own repository git push origin dev-fix dev-fix
The user configuration is in the project root directory /config/, the project startup script and the upgrade patch script are in the project root directory /bin/, the back-end code and core configuration are in the server/ directory, and the log is in the project root directory /log/. Note: The project root directory referred to here refers to the directory configured by the environment variable LINKIS_HOME, and environment variables need to be configured during IDE development. For example, Idea's priority regarding environment variable loading: Configured in Run/Debug Configurations
Environment variables
—> System environment variables cached by IDE.
├── bin # script directory ├── install.sh # One-click deployment script ├── start-all.sh # One-click start script └── stop-all.sh # One-click stop script
├── config # User configuration directory ├── config.sh # One-click deployment configuration file ├── db.sh # One-click deployment database configuration
Code directory structure
For details, see Linkis Code Directory Structure
Log directory
├── logs # log root directory
Configure system environment variable or IDE environment variable LINKIS_HOME, it is recommended to use IDE environment variable first.
Modify the application.yml
file in the resources/ directory of each microservice to configure related properties.
mvn clean package
in the root directory;mvn clean package
in the module directory.<type>(<scope>): <subject>
, for details, please refer to Ruan Yifeng's Commit message and Change log writing guide this article.Before contributing code, you can find out what kind of submissions are popular in Review. Simply put, if a submission can bring as many gains as possible and as few side effects or risks as possible, the higher the probability of it being merged, the faster the review will be. Submissions with high risk and low value are almost impossible to merge, and may be rejected Review.
If you have submitted a valuable PR to Linkis and have been merged, or contributed continuously for more than half a year, and have led the release of at least one version, you can find a PMC members of the Linkis project through the official WeChat group, if he is willing to nominate you as a committer , And are willing to state your contribution to all PMC members and Committer, then a vote will be initiated; PMC members and other Committers will vote together to decide whether to allow you to join, if you get enough votes, you will become Committer of the Linkis project .
If you are the Committer of the Linkis project, and all your contributions have been recognized by other Committee members, you can apply to become a member of the Linkis Committee, and other Committee members will vote together to decide whether to allow you to join. If you pass unanimously, you will become a member of the Linkis Committee.