From 2114397759ae742fbea8f229e7f910d17953c440 Mon Sep 17 00:00:00 2001 From: Aditya Bisht Date: Sat, 14 Sep 2024 10:29:37 +0530 Subject: [PATCH] feat: add CONTRIBUTING.md & CODING_GUIDELINES.md --- CODING_GUIDELINES.md | 98 +++++++++++++++ CONTRIBUTING.md | 116 ++++++++++++++++++ .../cloudbuild-base.yml | 0 .../cloudbuild-relayer.yml | 0 4 files changed, 214 insertions(+) create mode 100644 CODING_GUIDELINES.md create mode 100644 CONTRIBUTING.md rename cloudbuild-base.yaml => kubernetes/cloudbuild-base.yml (100%) rename cloudbuild-relayer.yaml => kubernetes/cloudbuild-relayer.yml (100%) diff --git a/CODING_GUIDELINES.md b/CODING_GUIDELINES.md new file mode 100644 index 00000000..195805e5 --- /dev/null +++ b/CODING_GUIDELINES.md @@ -0,0 +1,98 @@ +# Coding Guidelines for Relayer Utils + +This document outlines the coding guidelines for contributing to Relayer Utils. Following these guidelines will help maintain a consistent and high-quality codebase. + +## 1. Code Formatting + +- **Tool**: Use `rustfmt` to automatically format your code. Ensure that all code is formatted before committing. Run `cargo fmt` to format your code according to the project's style guidelines. +- **Indentation**: Use 4 spaces per indentation level. Do not use tabs. +- **Line Length**: Aim to keep lines under 100 characters, but it's not a strict rule. Use your judgment to ensure readability. +- **Imports**: Group imports into four sections: `extern crate`, `use`, `use crate`, and `use super`. + - Example: + ```rust + extern crate serde; + + use std::collections::HashMap; + use std::io::{self, Read}; + + use crate::utils::config; + + use super::super::common::logger; + ``` +- **Braces**: Use the Allman style for braces, where the opening brace is on the same line as the function signature. + - Example: + ```rust + fn main() { + // function body + } + ``` +- **Comments**: Use `//` for single-line comments and `/* ... */` for multi-line comments. +- **Whitespace**: Use a single space after commas and colons, and no space before commas and colons. + - Example: + ```rust + let numbers = vec![1, 2, 3]; + let user = User { name: "Alice", age: 30 }; + ``` +- **Function Length**: Aim to keep functions short and focused. If a function is too long, consider breaking it up into smaller functions. +- **Code Duplication**: Avoid duplicating code. If you find yourself copying and pasting code, consider refactoring it into a shared function or module. +- **No warnings**: Ensure that your code compiles without warnings. Fix any warnings before committing. + +## 2. Code Linting + +- **Tool**: Use `cargo clippy` to lint your code and catch common mistakes and improve your Rust code. Run `cargo clippy` before committing your code to ensure it adheres to Rust's best practices and the project's specific requirements. +- **Handling Lints**: Address all warnings and errors reported by `clippy`. If you must ignore a lint, use `#[allow(clippy::lint_name)]` and provide a comment explaining why. + +## 3. Naming Conventions + +- **Variables and Functions**: Use `snake_case`. + - Example: `let user_name = "Alice";` +- **Structs and Enums**: Use `PascalCase`. + - Example: `struct UserAccount { ... }` +- **Constants**: Use `UPPER_SNAKE_CASE`. + - Example: `const MAX_USERS: u32 = 100;` +- **Module Names**: Use `snake_case`. + - Example: `mod user_account;` + +## 4. Documentation + +- **Public Items**: All public functions, structs, and modules must have documentation comments using `///`. + - Example: + ```rust + /// Creates a new user account. + /// + /// # Arguments + /// + /// * `name` - The name of the user. + /// + /// # Returns + /// + /// A `UserAccount` struct. + pub fn create_user_account(name: &str) -> UserAccount { + // function body + } + ``` +- **Private Items**: Document private items where the intent or functionality is not immediately clear. +- **Module Documentation**: Each module should have a comment at the top explaining its purpose. + - Example: + ```rust + //! This module contains utility functions for user management. + + // module contents + ``` + +## 5. Error Handling + +- **Use of `Result` and `Option`**: + - Use `Result` for operations that can fail and `Option` for values that may or may not be present. + - Example: + ```rust + fn find_user(id: u32) -> Option { + // function body + } + + fn open_file(path: &str) -> Result { + // function body + } + ``` +- **Custom Error Types**: When appropriate, define custom error types using `enum` and implement the `anyhow::Error` trait. +- **Error Propagation**: Propagate errors using `?` where possible to simplify error handling. \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..39a0dcee --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,116 @@ +# Contributing to Relayer Utils + +Thank you for considering contributing to our project! We welcome contributions of all kinds, including code, documentation, bug reports, feature requests, and more. This document outlines the process for contributing to this project. + +## Table of Contents +- [Contributing to Relayer Utils](#contributing-to-relayer-utils) + - [Table of Contents](#table-of-contents) + - [1. Code of Conduct](#1-code-of-conduct) + - [2. Getting Started](#2-getting-started) + - [3. Coding Guidelines](#3-coding-guidelines) + - [4. Testing](#4-testing) + - [5. Commit Messages](#5-commit-messages) + - [6. Pull Request Process](#6-pull-request-process) + - [7. Contact](#7-contact) + +## 1. Code of Conduct +We are committed to providing a welcoming and inspiring community for all and expect our Code of Conduct to be honored. Anyone who violates this code of conduct may be banned from the community. + +Our community strives to: + +- **Be friendly and patient.** +- **Be welcoming**: We strive to be a community that welcomes and supports people of all backgrounds and identities. +- **Be considerate**: Your work will be used by other people, and you in turn will depend on the work of others. +- **Be respectful**: Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. +- **Be careful in the words that you choose**: We are a community of professionals, and we conduct ourselves professionally. +- **Be kind to others**: Do not insult or put down other participants. Harassment and other exclusionary behavior aren't acceptable. + +This includes, but is not limited to: + +- Violent threats or language directed against another person. +- Discriminatory jokes and language. +- Posting sexually explicit or violent material. +- Posting (or threatening to post) other people's personally identifying information ("doxing"). +- Personal insults, especially those using racist or sexist terms. +- Unwelcome sexual attention. +- Advocating for, or encouraging, any of the above behavior. +- Repeated harassment of others. In general, if someone asks you to stop, then stop. + +Moderation + +These are the policies for upholding our community’s standards of conduct. If you feel that a thread needs moderation, please contact the community team at [paradox@pse.dev](mailto:paradox@pse.dev). + +1. **Remarks that violate the Relayer Utils standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed.** (Cursing is allowed, but never targeting another user, and never in a hateful manner.) +2. **Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed.** +3. **Moderators will first respond to such remarks with a warning.** +4. **If the warning is unheeded, the user will be “kicked,” i.e., temporarily banned from the community.** +5. **If the user comes back and continues to make trouble, they will be banned permanently from the community.** +6. **Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology.** +7. **If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, in a private discussion.** + +**Please try to emulate these behaviors, especially when debating the merits of different options.** + +Thank you for helping make this a welcoming, friendly community for all. + +This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 1.4, available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html) + + +## 2. Getting Started +To start contributing, follow these steps: + +1. Fork the repository. +2. Clone your fork to your local machine: + ```bash + git clone https://github.com/zkemail/relayer-utils.git + ``` +3. Create a new branch for your feature or bugfix: + ```bash + git checkout -b feat/your-feature-name + ``` +4. Install the necessary dependencies: + ```bash + cargo build + ``` +5. Make your changes. + +## 3. Coding Guidelines + +Please follow the coding guidelines in [CODING_GUIDELINES.md](CODING_GUIDELINES.md) when contributing to this project. + +## 4. Testing + +Please write tests for your contributions. We aim for high test coverage. + + • Unit Tests: Place unit tests in the same file as the code they are testing. + • Integration Tests: Place integration tests in the tests/ directory. + +Run all tests before submitting your code with cargo test. + +Run all tests before submitting your code with cargo test. + +## 5. Commit Messages + +Use conventional commit messages for your commits. This helps us automatically generate the changelog and follow semantic versioning. + + • Format: `: ` + • Example: `feat: add new feature` + +For more information, see [Conventional Commits](https://www.conventionalcommits.org/). + +## 6. Pull Request Process + + 1. Ensure your branch is up-to-date with the main branch: + • git fetch origin + • git checkout main + • git merge origin/main + 2. Push your branch to your fork: + • git push origin feature/your-feature-name + 3. Open a pull request from your branch to the main branch of the original repository. + 4. Ensure that your pull request passes all checks (e.g., CI tests). + 5. A reviewer will review your pull request. Be prepared to make adjustments based on feedback. + +## 7. Contact + +If you have any questions or need further assistance, feel free to open an issue or contact us at [paradox@pse.dev](mailto:paradox@pse.dev). + +Thank you for your contributions! \ No newline at end of file diff --git a/cloudbuild-base.yaml b/kubernetes/cloudbuild-base.yml similarity index 100% rename from cloudbuild-base.yaml rename to kubernetes/cloudbuild-base.yml diff --git a/cloudbuild-relayer.yaml b/kubernetes/cloudbuild-relayer.yml similarity index 100% rename from cloudbuild-relayer.yaml rename to kubernetes/cloudbuild-relayer.yml