Contributing to Bank Statement Separator¶
Thank you for your interest in contributing to the Bank Statement Separator project! This document provides guidelines for contributing to the project.
Development Setup¶
- Fork the repository
- Clone your fork:
git clone https://github.com/your-username/bank-statement-separator.git - Install dependencies:
uv sync - Create a feature branch:
git checkout -b feature/your-feature-name
Code Style¶
- Follow PEP 8 conventions
- Use type hints for all functions
- Write docstrings for public APIs
- Keep functions focused and small
- Use f-strings for string formatting
Testing¶
- Write tests for new features
- Run tests with:
uv run pytest - Ensure all tests pass before submitting PR
- Add regression tests for bug fixes
Security¶
Secret Detection¶
This project uses detect-secrets to prevent accidental commits of sensitive information:
- Pre-commit hook: Automatically scans for potential secrets before commits
- Baseline file:
.secrets.baselinecontains known false positives - Exclusions: Test environment files and documentation are excluded
Working with detect-secrets¶
# Scan for new secrets
uv run detect-secrets scan
# Update baseline with new legitimate secrets
uv run detect-secrets scan --baseline .secrets.baseline
# Audit findings interactively
uv run detect-secrets audit .secrets.baseline
Common Issues¶
- False positives: Add to baseline or use
# pragma: allowlist secretcomments - Test files: Use placeholder values like
sk-test-keyoryour-api-key-here - Documentation: Real examples should use obviously fake credentials
Conventional Commits¶
This project uses Conventional Commits for automated semantic versioning. Please follow these guidelines:
Commit Message Format¶
Types¶
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, etc.)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing tests or correcting existing tests
- build: Changes that affect the build system or external dependencies
- ci: Changes to CI configuration files and scripts
- chore: Other changes that don't modify src or test files
Examples¶
feat: add PDF boundary detection for multi-statement files
fix: resolve account number extraction for Westpac statements
docs: update installation instructions for uv package manager
refactor: simplify LLM analyzer node logic
test: add integration tests for API-dependent features
Breaking Changes¶
For breaking changes, add BREAKING CHANGE: in the footer:
Scope (Optional)¶
You can add a scope to provide more context:
Pull Request Process¶
- Ensure your code follows the style guidelines
- Write or update tests as needed
- Update documentation if required
- Ensure all CI checks pass
- Create a pull request with a clear description
- Wait for review and address any feedback
Release Process¶
Releases are automated using semantic versioning:
- Patch releases (1.0.0 → 1.0.1): Bug fixes (
fix:commits) - Minor releases (1.0.0 → 1.1.0): New features (
feat:commits) - Major releases (1.0.0 → 2.0.0): Breaking changes (
BREAKING CHANGE:footer)
The release process is fully automated:
- Conventional commits are analyzed on push to main
- Release PR is created/updated with changelog
- When merged, version is bumped and release is published
- PyPI package is automatically published
- Documentation is versioned and deployed
Getting Help¶
- Check existing issues and documentation
- Create an issue for bugs or feature requests
- Join discussions in pull request comments
Thank you for contributing! 🎉