We are happy to accept your patches and contributions to this project. You just need to follow some small guidelines.
We have a sample commit-msg hook in scripts/commit-msg.sh. Please run the following command to set it up:
On Windows, copy the commit-msg.sh file directly to .git/hooks/commit-msg.
This will run the following checks before each commit:
tsc Checks the code for syntax errors and unused variables and references.If you want to skip the hook, run git commit with the --no-verify option.
Fork & Clone the repository
Install dependencies
Copy the wrangler.example.toml file to wrangler.toml and fill in the necessary information
Normally, you only need to fill in the database_name and database_id fields.
S3 configuration is not required, but if you want to use the image upload feature, you need to fill in the S3
configuration.
client/.env.example file to client/.env and change the necessary configuration.Typically, you only need to fill in AVATAR, NAME and DESCRIPTION.
If your database name (database_name in wrangler.toml) is not rin
Please modify the DB_NAME field in scripts/dev-migrator.sh before performing the migration
.dev.vars' file Copy .dev.example.vars to .dev.vars` and fill in the required informationTypically, you need to fill in the RIN_GITHUB_CLIENT_ID and RIN_GITHUB_CLIENT_SECRET as well as
the JWT_SECRET fields.
In the development environment, you need to create a separate GitHub OAuth service with a callback address
of http://localhost:11498/user/github/callback
If you have changed the listening port of the server manually, please also change the port number in the callback
address.
Start the development server
For better control of the development server, you can run the client and server dev commands in two separate terminals:
for simple patches, they can usually be reviewed within 10 minutes during the day in the UTC+8 time zone. 2.
Do not force push minor changes after the PR is ready for review. Doing so forces maintainers to re-read your entire PR, which delays the review process. 3.
Always keep the CI green.
If the CI fails on your PR, do not push it. Even if you don't think it's the patch's fault. If something else is breaking the CI, help fix the root cause before you push.
Start writing code happily!
All commits, including those from project members, need to be reviewed. We use GitHub pull requests for this purpose. For more information on using pull requests, see the GitHub Help.