Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
204 lines (145 loc) · 5.82 KB

CONTRIBUTING.md

File metadata and controls

204 lines (145 loc) · 5.82 KB

Contribution Guide

First steps

The project requires Go 1.24 or later. Clone the repository and install dependencies.

$ git clone https://github.com/tarantool/go-storage
$ cd go-storage
$ go mod tidy

Branch naming conventions

When creating feature branches, follow these naming patterns:

  • <user.name>/gh-<issue-id>-short-description (for GitHub issues)
  • <user.name>/gh-no-short-description (for work not tied to an issue)
  • <user.name>/tntp-<issue-id>-short-description (for TNTP issues)

For release branches, use:

  • <user.name>/release-v<version>

Replace <user.name> with your Git username, <issue-id> with the issue number, and <short-description> with a brief description using lowercase, hyphen-separated words, do not use any symbols except numbers, letters and dashes.

Examples from existing branches:

  • bigbes/gh-22-redo-rsapsa-api
  • bigbes/tntp-4191-implement-storage
  • elhimov/tntp-4169-base-ci
  • patapenka-alexey/tntp-4190-namer
  • bigbes/release-v1.0.0

For more examples, look at existing branches by running git branch.

Although working on features without opened issue is possible - avoid that at all costs.

Running tests

# To run unit and integration tests for the main package and each subpackage:
make test

# To run tests with race detector:
make testrace

# To run tests for a specific package (e.g., `driver/etcd`):
go test ./driver/etcd

Test naming conventions

Follow these patterns when naming test functions:

// Unit test naming patterns
Test<FunctionName>_<Description>
Test<StructName>_<Method>_<Description>
Test<StructName><Method>_<Description>

// Integration test naming patterns (all above plus)
Test<Description>

Examples from the codebase: TestTypedGet_PassingModRevision, TestEtcdDriver_Put, TestTCSDriver_ValueEqualPredicate.

Integration tests

Integration tests require external dependencies:

  • etcd: Tests use etcd's embedded integration framework; no external setup needed.
  • Tarantool Config Storage (TCS): Tests require Tarantool EE SDK. If the SDK is not available, integration tests are skipped automatically.

If you have Tarantool EE SDK installed, set TARANTOOL_SDK_PATH environment variable to the SDK directory. The integration tests will automatically detect it.

Code coverage

To run tests with coverage collection:

make coverage

This generates a coverage profile and prints coverage statistics.

Examples

The project includes executable examples in the driver packages. To run the etcd examples:

go test -v -run Example ./driver/etcd

For TCS examples:

go test -v -run Example ./driver/tcs

Linting

To run the linter (golangci-lint) on the codebase:

make lint

This will automatically install golangci-lint if missing. The lint target also runs go mod tidy and go mod vendor to ensure dependency consistency.

Formatting

The project uses goimports for code formatting. The linter ensures formatting consistency. You can format your code with:

goimports -w .

Spell checking

To check for common misspellings in code and documentation:

make codespell

Code review checklist

  • Public API contains functions, variables, constants that are needed from outside by users. All the rest should be left closed.
  • Public functions, variables and constants contain at least a single-line comment.
  • Code is DRY (see "Do not Repeat Yourself" principle).
  • New features have functional and probably performance tests.
  • There are no changes in files not related to the issue.
  • There are no obvious flaky tests.
  • Commits with bugfixes have tests based on reproducers.
  • Changelog entry is present in CHANGELOG.md.
  • Public methods contain executable examples (contains a comment with reference output).
  • Autogenerated documentation looks good. Run godoc -http=:6060 and point your web browser to address "http://127.0.0.1:6060" for evaluating.
  • Commit message header may start with a prefix with a short description follows after colon. It is applicable to changes in a README, examples, tests and CI configuration files. Examples: github-ci: add Tarantool 2.x-latest and readme: describe how to run tests.
  • Check your comments, commit title, and even variable names to be grammatically correct. Start sentences from a capital letter, end with a dot. Everywhere - in the code, in the tests, in the commit message.

Commit message guidelines

Follow the Conventional Commits style:

  • feat: for new features
  • fix: for bug fixes
  • docs: for documentation changes
  • test: for test additions/modifications
  • refactor: for code refactoring
  • chore: for maintenance tasks

Example: feat: add support for etcd lease operations

Referencing issues in commit messages

When referencing issues in commit messages, use the appropriate prefix:

  • For GitHub issues: Use Closes #<issue-no>, Relates to #<issue-no>, Related to #<issue-no>, or Part of #<issue-no> in the commit body to automatically link the commit to the issue.
  • For TNTP issues: Use Closes TNTP-<issue-no>, Relates to TNTP-<issue-no>, Related to TNTP-<issue-no>, or Part of TNTP-<issue-no> (note: use TNTP- prefix instead of #).

Place these references in the commit body, not the subject line. These references are used by automation to track issue status.

Pull request process

  1. Fork the repository and create a feature branch.
  2. Ensure your code passes linting and tests.
  3. Update the CHANGELOG.md with a brief description of your changes.
  4. Submit a pull request with a clear description of the changes and their purpose.

Questions?

If you have questions, feel free to open an issue or reach out via Telegram (English / Russian).