Skip to content

Latest commit

 

History

History
145 lines (111 loc) · 6.01 KB

CONTRIBUTING.md

File metadata and controls

145 lines (111 loc) · 6.01 KB
Raw

Welcome

Welcome to CubeFS!

Contributing to CubeFS

Bug Reports

Please make sure the bug is not already reported by searching the repository with reasonable keywords. Then, open an issue with steps to reproduce.

Workflow

Recommend the standard GitHub flow based on forking and pull requests.

The following diagram and practice steps show the basic process of contributing code to CubeFS:

How to make contributing to CubeFS

  1. Fork CubeFS to your repository.
  2. Add remote for your forked repository.
    (Example: $ git remote add me https://github.com/your/cubefs)
  3. Make sure your local master branch synchronized with the master branch of main repository.
    (Example: $ git checkout master && git pull)
  4. Create local new branch from your up-to-dated local master branch, then checkout to it and leaves your changes.
    (Example: $ git branch your-branch && git checkout your-branch)
  5. Commit and push to your forked remote repository.
    (Example: $ git commit -s && git push me)
  6. Make a pull request that request merging your own branch on your forked repository into the master branch of the main repository.
    (Example: merge your/cubefs:your-branch into cubefs/cubefs:master)

Note 1:
The DOC Check is enabled and required. Please make sign your commit by using -s argument to add a valid Signed-off-by line at bottom of your commit message.
Example:

$ git commit -s

Note 2:
If your pull request solves an existing issue or implements a feature request with an existing issue. Please use the fixes keyword in the pull request to associate the pull request with the relevant issue.

Note 3:
Every pull request that merges code to the master branch needs to be approved by at least one core maintainer for code review and pass all checks (including the DCO check) before it can be merged.

Contributor Recruitment

Development Guide

Coding Style

  • Prepare some code checking tools. 
    # gofumpt
> go install mvdan.cc/gofumpt@latest

# golangci-lint
> go install github.com/golangci/golangci-lint/cmd/[email protected]
  • Follow the coding standards of Go.
  • Ensure that your code is formatted using gofumpt before submitting it. 
    > gofumpt -l -w .
  • Run some indispensable go lints on the project with your new code. 
    > go generate .

# OR run in local docker
> ./docker/run_docker.sh --format
  • Ensure that each new source file starts with a license header.
  • Ensure that there are enough unit tests.
  • Ensure that there are well-documented comments.

Commit Message Guidelines

  • Follow the Angular commit guidelines. 
    <type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
"close: #<issue_id>"
<BLANK LINE>
<footer>
"Signed-off-by: <name> <email>"
  • Commits must be signed and the signature must match the author git commit --signoff.
  • If there is an issue, you need to link to related issues.
  • The subject and line of body should not exceed 100 bytes.

Example:

For example, the author information must match the Signed-off-by information.

Author: users <[email protected]>
Date:   Thu Apr 27 09:40:02 2023 +0800

    feat(doc): this is an example

    body's first line, explain more details of this commit,
    new line if the body is more than 100 bytes.

    close: #1

    empty or anything else
    Signed-off-by: users <[email protected]>

TestCase Guidelines

  • Clear Test Purpose: Ensure each test case clearly states its purpose and what functionality it is verifying.
  • Comprehensive Coverage: Aim for comprehensive coverage, including edge cases, typical use cases, and error conditions.
  • Descriptive Names: Use descriptive names for your test functions to indicate what they are testing.
  • Automated Tests: Ensure that tests can be run automatically and are integrated into the CI/CD pipeline.
  • Consistent Style: Follow consistent coding and testing styles to enhance readability and maintainability.
  • Review and Refactor: Regularly review and refactor test cases to keep them relevant and efficient as the codebase evolves.

Github Workflows

  • codeql: Basic security code scanning.
  • ci: Run code format, unit test and coverage, s3 service testing and gosec.
  • check_pull_request: Check pull request title and new commit messages.
  • goreleaser: Build release package.
  • slsa-releaser: Build release package with SLSA.
  • release_test: Run ltp tests before released.

Development, Testing, and Troubleshooting Guidelines