External/securelens-backend
1
0
Fork 0
mirror of https://github.com/Rarebuffalo/securelens-backend.git synced 2026-06-19 07:00:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

update contributing guidelines with local setup and automation shortcuts

Browse Source
This commit is contained in:
rarebuffalo
2026-06-12 19:35:33 +05:30
parent 6c543f1a9a
commit e8c30b04cb
1 changed files with 37 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
CONTRIBUTING.md
View File

@@ -6,7 +6,15 @@ Welcome to SecureLens! We appreciate your interest in contributing to the projec
## Code of Conduct ## Code of Conduct
By participating in this project, you agree to abide by our Code of Conduct. Please read `CODE_OF_CONDUCT.md` to understand the expectations we have for community members. By participating in this project, you agree to abide by our Code of Conduct. Please read [CODE_OF_CONDUCT.md](file:///home/Krishna-Singh/securelens-backend/CODE_OF_CONDUCT.md) to understand the expectations we have for community members.
---
## Where to Start?
If you are a first-time contributor or looking for a quick way to get involved, head over to our GitHub Issues tab. We actively maintain labels like:
* **`good first issue`** - Small, isolated tasks perfect for getting familiar with the repository layout.
* **`help wanted`** - Features, bugs, or refactoring tasks that are high priority for our current roadmap.
--- ---
@@ -40,22 +48,31 @@ To submit code changes:
### 1. Code Style ### 1. Code Style
We enforce standard Python formatting to keep the codebase maintainable and readable: We enforce standard Python formatting to keep the codebase maintainable and readable:
* Use standard line length limits (79 or 88 characters). * Use standard line length limits (88 characters).
* Use explicit type hinting for function arguments and return values where possible. * Use explicit type hinting for function arguments and return values where possible.
* Document modules, classes, and public functions with clear docstrings. * Document modules, classes, and public functions with clear docstrings.
### 2. Linting and Formatting ### 2. Linting, Formatting & Pre-Commit
Run linting checks before committing. We recommend installing our pre-commit hook framework to automate these checks natively from your git environment:
Run linting checks before committing. If you use formatters like `black` or `ruff`:
```bash ```bash
# Format the code base # Install the hooks locally
black app/ cli/ tests/ pre-commit install
# Run static analysis # Manually run checks against all files
ruff check app/ cli/ tests/ pre-commit run --all-files
``` ```
We recommend installing the pre-commit hook framework to automate checks (see `.pre-commit-config.yaml`). If you prefer to run individual formatters and linters manually (or via our project shortcuts):
```bash
# Run via Makefile automation
make lint
# Or run manually
black app/ cli/ tests/
ruff check app/ cli/ tests/
```
### 3. Running the Test Suite ### 3. Running the Test Suite
@@ -63,6 +80,10 @@ We use `pytest` for unit and integration testing. All tests are located under th
Run the entire test suite locally: Run the entire test suite locally:
```bash ```bash
# Run via Makefile automation
make test
# Or run manually
pytest tests/ -v pytest tests/ -v
``` ```
@@ -73,6 +94,8 @@ pytest tests/test_cli_sync.py -v
pytest tests/test_cli_pdf.py -v pytest tests/test_cli_pdf.py -v
``` ```
Refer to [test_cli_patterns.py](file:///home/Krishna-Singh/securelens-backend/tests/test_cli_patterns.py), [test_cli_sync.py](file:///home/Krishna-Singh/securelens-backend/tests/test_cli_sync.py), and [test_cli_pdf.py](file:///home/Krishna-Singh/securelens-backend/tests/test_cli_pdf.py) for examples of testing our offline scanner, sync clients, and PDF exporters.
Ensure all tests pass and write new tests covering any logic changes or new features you introduce. Ensure all tests pass and write new tests covering any logic changes or new features you introduce.
--- ---
@@ -80,7 +103,8 @@ Ensure all tests pass and write new tests covering any logic changes or new feat
## Pull Request Guidelines ## Pull Request Guidelines
To help maintainers review your PR efficiently: To help maintainers review your PR efficiently:
* Keep PRs focused. Do not combine multiple unrelated changes into one pull request. * **Keep PRs focused.** Do not combine multiple unrelated changes into one pull request.
* Write a clear title and description explaining what was changed and why. * **Provide context.** Write a clear title and description explaining what was changed and why.
* Reference any related issues (e.g., `Closes #123`). * **Link your issues.** Reference any related issues (e.g., `Closes #123`) so they close automatically upon merge.
* Verify that your branch is rebased on top of the latest `main` branch. * **Stay updated.** Verify that your branch is rebased on top of the latest upstream `main` branch.
* **CI Validation:** Every PR triggers an automated workflow running our formatting and test suites. PRs cannot be merged until these checks pass.