Skip to content

Latest commit

 

History

History
100 lines (68 loc) · 3.14 KB

DEVELOPMENT.md

File metadata and controls

100 lines (68 loc) · 3.14 KB

Welcome to the portgraph development guide

This guide is intended to help you get started with developing portgraph.

If you find any errors or omissions in this document, please open an issue!

#️⃣ Setting up the development environment

You can setup the development environment you will need:

You can use the git hook in .github/pre-commit to automatically run the test and check formatting before committing. To install it, run:

ln -s .github/pre-commit .git/hooks/pre-commit
# Or, to check before pushing instead
ln -s .github/pre-commit .git/hooks/pre-push

🏃 Running the tests

To compile and test the rust code, run:

cargo build
cargo test

Run the benchmarks with:

cargo bench

Finally, if you have rust nightly installed, you can run miri to detect undefined behaviour in the code.

cargo +nightly miri test

💅 Coding Style

The rustfmt tool is used to enforce a consistent rust coding style. The CI will fail if the code is not formatted correctly.

To format your code, run:

# Format rust code
cargo fmt

We also check for clippy warnings, which are a set of linting rules for rust. To run clippy, run:

cargo clippy --all-targets

📈 Code Coverage

We run coverage checks on the CI. Once you submit a PR, you can review the line-by-line coverage report on codecov.

To run the coverage checks locally, install cargo-llvm-cov, generate the report with:

cargo llvm-cov --lcov > lcov.info

and open it with your favourite coverage viewer. In VSCode, you can use coverage-gutters.

🌐 Contributing to portgraph

We welcome contributions to portgraph! Please open an issue or pull request if you have any questions or suggestions.

PRs should be made against the main branch, and should pass all CI checks before being merged. This includes using the conventional commits format for the PR title.

The general format of a contribution title should be:

<type>(<scope>)!: <description>

Where the scope is optional, and the ! is only included if this is a semver breaking change that requires a major version bump.

We accept the following contribution types:

  • feat: New features.
  • fix: Bug fixes.
  • docs: Improvements to the documentation.
  • style: Formatting, missing semi colons, etc; no code change.
  • refactor: Refactoring code without changing behaviour.
  • perf: Code refactoring focused on improving performance.
  • test: Adding missing tests, refactoring tests; no production code change.
  • ci: CI related changes. These changes are not published in the changelog.
  • chore: Updating build tasks, package manager configs, etc. These changes are not published in the changelog.
  • revert: Reverting previous commits.