build(make): require cargo-nextest for make test with explicit escape hatch (backlog#1153 infra-14) cargo-nextest changes test semantics — it runs each test in its own process (so serial_test's #[serial] mutex does not serialize across tests) and is the only runner that honours .config/nextest.toml [test-groups] (e.g. the ecstore-serial-flaky serialization guard). CI installs and runs nextest, but `make test` only warned when it was missing and then silently fell back to `cargo test`, which runs with different serialization behaviour than CI and can mask or invent flakes. Make cargo-nextest a hard dependency of `make test`: - Missing nextest now fails `make test` with a clear message and install instructions (`cargo install cargo-nextest --locked` or a prebuilt binary via https://nexte.st/docs/installation/). - Set RUSTFS_ALLOW_CARGO_TEST_FALLBACK=1 to opt into the plain `cargo test` fallback anyway; it prints a loud warning that serialization semantics differ from CI and .config/nextest.toml test-groups will NOT apply. - The check stays cheap (command -v). The warn-only test-deps prerequisite is dropped from check.mak in favour of recipe-level gating. Install docs live in the make-layer error message plus a header comment in tests.mak, with a single-line note in CONTRIBUTING.md (kept minimal to avoid conflicting with #4667 / infra-9, which rewrites the verification sections). No CI change: .github/workflows/ci.yml already runs cargo nextest and .github/actions/setup/action.yml already installs it. Refs rustfs/backlog#1153 (infra-14), master plan #1155. Signed-off-by: Zhengchao An <anzhengchao@gmail.com>
6.9 KiB
RustFS Development Guide
📋 Code Quality Requirements
This guide covers the local development environment and the checks expected before contributing.
🔧 Code Formatting Rules
MANDATORY: All code must be properly formatted before committing. This project enforces strict formatting standards to maintain code consistency and readability.
Verification Requirements
Before submitting your changes for review, you MUST:
-
Format your code:
cargo fmt --all -
Verify formatting:
cargo fmt --all --check -
Pass clippy checks:
cargo clippy --all-targets --all-features -- -D warnings -
Ensure compilation:
cargo check --all-targets
Quick Commands
We provide convenient Makefile targets for common tasks:
# Format all code
make fmt
# Check if code is properly formatted
make fmt-check
# Run clippy checks (all targets, all features, -D warnings)
make clippy-check
# Fast workspace compilation check (excludes e2e_test)
make quick-check
# Full compilation check (cargo check --all-targets)
make compilation-check
# Run tests (shell script tests + workspace tests + doc tests)
make test
# Fast pre-commit gate — see below for exactly what it runs
make pre-commit
# Full pre-PR gate (pre-commit gates + clippy + tests)
make pre-pr
make testrequires cargo-nextest (CI runs it and only nextest honours.config/nextest.tomltest-groups). Install it withcargo install cargo-nextest --lockedor a prebuilt binary (see https://nexte.st/docs/installation/). To run the plaincargo testfallback anyway (results not authoritative — serialization semantics differ from CI), setRUSTFS_ALLOW_CARGO_TEST_FALLBACK=1.
🔒 Automated Pre-commit Hooks
What make pre-commit and make pre-pr actually run
make pre-commit is the fast gate. It runs, in order
(see .config/make/pre-commit.mak):
fmt-check—cargo fmt --all --checkunsafe-code-check—./scripts/check_unsafe_code_allowances.sharchitecture-migration-check—./scripts/check_architecture_migration_rules.shlogging-guardrails-check—./scripts/check_logging_guardrails.shtokio-io-uring-check—./scripts/check_no_tokio_io_uring.shdoc-paths-check—./scripts/check_doc_paths.shquick-check—cargo check --workspace --exclude e2e_test
make pre-commit does NOT run clippy and does NOT run any tests.
A green make pre-commit is not enough to open a pull request.
make pre-pr is the full gate: it runs all of the guard checks above,
then clippy-check (cargo clippy --all-targets --all-features -- -D warnings)
and test (shell script tests, workspace tests excluding e2e_test, and doc
tests). Run make pre-pr before opening or updating a pull request — this is
what CI enforces.
🔒 Git Pre-commit Hooks (optional)
Git hooks are not versioned in this repository, so a fresh clone has no
active pre-commit hook. If you add your own .git/hooks/pre-commit (a good
choice is a one-liner that runs make pre-commit), you can mark it executable
with:
make setup-hooks
Or manually:
chmod +x .git/hooks/pre-commit
With or without a hook, the expectation is the same: run make pre-commit
before committing and make pre-pr before opening a pull request.
📝 Formatting Configuration
The project uses the following rustfmt configuration (defined in rustfmt.toml):
max_width = 130
fn_call_width = 90
single_line_let_else_max_width = 100
🚫 Commit Prevention
If you set up a pre-commit hook and your code doesn't meet the formatting requirements, the hook will:
- Block the commit and show clear error messages
- Provide exact commands to fix the issues
- Guide you through the resolution process
Example output when formatting fails:
❌ Code formatting check failed!
💡 Please run 'cargo fmt --all' to format your code before committing.
🔧 Quick fix:
cargo fmt --all
git add .
git commit
🔄 Development Workflow
- Make your changes
- Format your code:
make fmtorcargo fmt --all - Run the fast gate:
make pre-commit(no clippy, no tests) - Commit your changes:
git commit -m "your message" - Run the full gate before opening/updating a PR:
make pre-pr(clippy + tests) - Push to your branch:
git push
🛠️ IDE Integration
VS Code
Install the rust-analyzer extension and add to your settings.json:
{
"rust-analyzer.rustfmt.extraArgs": ["--config-path", "./rustfmt.toml"],
"editor.formatOnSave": true,
"[rust]": {
"editor.defaultFormatter": "rust-lang.rust-analyzer"
}
}
Other IDEs
Configure your IDE to:
- Use the project's
rustfmt.tomlconfiguration - Format on save
- Run clippy checks
❗ Important Notes
- Never bypass formatting checks - they are there for a reason
- All CI/CD pipelines will also enforce these same checks
- Pull requests will be automatically rejected if formatting checks fail
- Consistent formatting improves code readability and reduces merge conflicts
🆘 Troubleshooting
Pre-commit hook not running?
# Check if hook is executable
ls -la .git/hooks/pre-commit
# Make it executable if needed
chmod +x .git/hooks/pre-commit
Formatting issues?
# Format all code
cargo fmt --all
# Check specific issues
cargo fmt --all --check --verbose
Clippy issues?
# See detailed clippy output
cargo clippy --all-targets --all-features -- -D warnings
# Fix automatically fixable issues
cargo clippy --fix --all-targets --all-features
📝 Pull Request Guidelines
Language Requirements
All Pull Request titles and descriptions MUST be written in English.
This ensures:
- Consistency across all contributions
- Accessibility for international contributors
- Better integration with automated tools and CI/CD systems
- Clear communication in a globally understood language
PR Description Requirements
When creating a Pull Request, ensure:
- Title: Use English and follow Conventional Commits format (e.g.,
fix: improve s3-tests readiness detection) - Description: Write in English, following the PR template format
- Code Comments: Must be in English (as per coding standards)
- Commit Messages: Must be in English (as per commit guidelines)
PR Template
Always use the PR template (.github/pull_request_template.md) and fill in all sections:
- Type of Change
- Related Issues
- Summary of Changes
- Checklist
- Impact
- Additional Notes
Note: While you may communicate with reviewers in Chinese during discussions, the PR itself (title, description, and all formal documentation) must be in English.
Following these guidelines ensures high code quality and smooth collaboration across the RustFS project! 🚀