Contributing

Parseable Contribution Guide | Parseable

Thank you for considering to contribute to Parseable. The goal of this document is to provide everything you need to start your contribution. We encourage contributions other than writing code:

  • Writing tutorials or blog posts.
  • Improving the documentation.
  • Submitting bug reports

Assumptions

  1. You're familiar with GitHub Pull Requests(PR) workflow
  2. You've read the Parseable documentation
  3. Your change has an issue. Find an existing issue or open a new issue.
  4. You've discussed the with Parseable community

How to Contribute

  1. Fork the Parseable repository in your own GitHub account.
  2. Create a new Git branch
  3. Review the Development Workflow section that describes the steps to maintain the repository.
  4. Make your changes on your branch.
  5. Submit the branch as a Pull Request pointing to the main branch of the Parseable repository. A maintainer should comment and/or review your Pull Request within a few days.

Development Workflow

We recommend Linux or macOS as the development platform for Parseable.

Setup and run Parseable

Parseable needs Rust 1.63 or above. Use the below command to build and run Parseable binary with local mode.

cargo run --release local-store

We recommend using the --release flag to test the full performance of Parseable.

Running Tests

cargo test

This command will be triggered to each PR as a requirement for merging it.

If you get a "Too many open files" error you might want to increase the open file limit using this command:

ulimit -Sn 3000

If you get a "OpenSSL" related error while building Parseable, you might need to install the dependencies using this command:

sudo apt install build-essential
sudo apt-get install libssl-dev
sudo apt-get install pkg-config

Git Guidelines

  1. The PR title should be accurate and descriptive of the changes.
  2. The draft PRs are recommended when you want to show that you are working on something and make your work visible. Convert your PR as a draft if your changes are a work in progress. Maintainers will review the PR once you mark your PR as ready for review.
  3. The branch related to the PR must be up-to-date with main before merging. We use Bors to automatically enforce this requirement without the PR author having to rebase manually.
Updated on