Contributing to DaemonEye
Thank you for your interest in contributing to DaemonEye! This guide will help you get started with contributing to the project.
Getting Started
Prerequisites
Before contributing to DaemonEye, ensure you have:
- Rust 1.90+: Latest stable Rust toolchain
- Git: Version control system
- Docker: For containerized testing (optional)
- Just: Task runner (install with cargo install just)
- Editor: VS Code with Rust extension (recommended)
Fork and Clone
- Fork the repository on GitHub
- Clone your fork locally:
git clone https://github.com/your-username/daemoneye.git
cd daemoneye
- Add the upstream repository:
git remote add upstream https://github.com/EvilBit-Labs/daemoneye.git
Development Setup
- Install dependencies:
just setup
- Run tests to ensure everything works:
just test
- Build the project:
just build
Development Environment
Project Structure
DaemonEye/
├── procmond/ # Process monitoring daemon
├── daemoneye-agent/ # Agent orchestrator
├── daemoneye-cli/ # CLI interface
├── daemoneye-lib/ # Shared library
├── docs/ # Documentation
├── tests/ # Integration tests
├── examples/ # Example configurations
├── justfile # Task runner
├── Cargo.toml # Workspace configuration
└── README.md # Project README
Workspace Configuration
DaemonEye uses a Cargo workspace with the following structure:
[workspace]
resolver = "2"
members = [
"procmond",
"daemoneye-agent",
"daemoneye-cli",
"daemoneye-lib",
]
[workspace.dependencies]
tokio = { version = "1.0", features = ["full"] }
clap = { version = "4.6.0", features = ["derive", "completion"] }
serde = { version = "1.0", features = ["derive"] }
sqlx = { version = "0.7", features = ["runtime-tokio-rustls", "sqlite"] }
sysinfo = "0.30"
tracing = "0.1"
thiserror = "1.0"
anyhow = "1.0"
Development Commands
just setup # Setup development environment
just build # Build the project
just test # Run tests
just lint # Run linting
just fmt # Format code
just bench # Run all workspace benchmarks
just bench-procmond # Run procmond benchmarks (WAL, EventBus, process collection, serialization)
just docs # Generate documentation
just clean # Clean build artifacts
Commit Signing and GPG Setup
Workspace tooling enforces signed commits (git.enableCommitSigning) and a rebase-first sync strategy. Configure GPG before making changes to avoid commit failures.
- Install GnuPG
- macOS:
brew install gnupg pinentry-mac - Linux: install gnupg and an appropriate pinentry package via your package manager
- Windows: install Gpg4win and enable the GPG Agent during setup
- macOS:
- Generate a signing key (4096-bit RSA recommended)
gpg --full-generate-key
- Locate the long key ID
gpg --list-secret-keys --keyid-format=long
- Export the public key for review systems
gpg --armor --export <KEY_ID> > ~/.gnupg/daemoneye.pub
- Configure Git to sign by default
git config --global user.signingkey <KEY_ID>
git config --global commit.gpgsign true
git config --global tag.gpgsign true
git config --global gpg.program $(command -v gpg)
- Ensure the GPG agent is active
- macOS: add
pinentry-program /opt/homebrew/bin/pinentry-macto~/.gnupg/gpg-agent.conf, then rungpgconf --kill gpg-agent - Windows: restart the "GnuPG Agent" service from the Gpg4win config utility
- Linux: ensure gpg-agent starts from your desktop session
- macOS: add
- Verify signing works
echo "test" | gpg --clearsign
git commit --allow-empty -S -m "test: verify signing"
gpg: signing failed: No secret key--- confirm the key ID in git config matchesgpg --list-secret-keysgpg: signing failed: Inappropriate ioctl for device--- configure an appropriate pinentry program and restart gpg-agent- Emergency opt-out (e.g., broken key) --- run
git config commit.gpgsign falselocally and notify the maintainers
Code Standards
Rust Standards
DaemonEye follows strict Rust coding standards:
- Edition: Always use Rust 2024 Edition
- Linting: Zero warnings policy with
cargo clippy -- -D warnings - Safety:
unsafe_code = "forbid"enforced at workspace level - Formatting: Standard rustfmt with 119 character line length
- Error Handling: Use thiserror for structured errors, anyhow for error context
Naming Conventions
- Functions: snake_case
- Variables: snake_case
- Types: PascalCase
- Constants: SCREAMING_SNAKE_CASE
- Modules: snake_case
- Files: snake_case.rs
Testing Requirements
Test Coverage
All code must have comprehensive test coverage:
- Unit Tests: Test individual functions and methods
- Integration Tests: Test component interactions
- End-to-End Tests: Test complete workflows
- Property Tests: Test with random inputs
- Fuzz Tests: Test with malformed inputs
Running Tests
cargo test # Run all tests
cargo test test_process_collection # Run specific test
cargo test -- --nocapture # Run tests with output
cargo test --test integration # Run integration tests
cargo bench # Run benchmarks
cargo fuzz run process_info # Run fuzz tests
Pull Request Process
Before Submitting
- Sync with upstream:
git fetch upstream
git checkout main
git merge upstream/main
- Create a feature branch:
git checkout -b feature/your-feature-name
- Make your changes: Write code following the coding standards, add comprehensive tests, update documentation, run all tests and linting
- Commit your changes:
git add .
git commit -m "feat: add new feature description"
Commit Message Format
Use conventional commits format:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
- feat: New feature
- fix: Bug fix
- docs: Documentation changes
- style: Code style changes
- refactor: Code refactoring
- test: Test changes
- chore: Build process or auxiliary tool changes
Pull Request Guidelines
- Title: Clear, descriptive title
- Description: Detailed description of changes
- Tests: Ensure all tests pass
- Documentation: Update relevant documentation
- Breaking Changes: Clearly mark any breaking changes
- Related Issues: Link to related issues
Issue Reporting
Bug Reports
When reporting bugs, please include:
- Environment: OS, Rust version, DaemonEye version
- Steps to Reproduce: Clear, numbered steps
- Expected Behavior: What should happen
- Actual Behavior: What actually happens
- Logs: Relevant log output
- Screenshots: If applicable
Feature Requests
When requesting features, please include:
- Use Case: Why is this feature needed?
- Proposed Solution: How should it work?
- Alternatives: Other solutions considered
- Additional Context: Any other relevant information
Community Guidelines
Code of Conduct
We are committed to providing a welcoming and inclusive environment for all contributors. Please:
- Be respectful and constructive
- Focus on what is best for the community
- Show empathy towards other community members
- Accept constructive criticism gracefully
- Help others learn and grow
Communication
- GitHub Issues: For bug reports and feature requests
- GitHub Discussions: For questions and general discussion
- Pull Requests: For code contributions
- Discord: For real-time chat (invite link in README)
Development Workflow
Branch Strategy
- main: Production-ready code
- develop: Integration branch for features
- feature/*: Feature development branches
- bugfix/*: Bug fix branches
- hotfix/*: Critical bug fixes
Continuous Integration
All pull requests must pass: Unit tests, Integration tests, Linting checks, Security scans, Performance benchmarks, Documentation builds.
License
By contributing to DaemonEye, you agree that your contributions will be licensed under the same license as the project (Apache 2.0 for core features, commercial license for business/enterprise features).
Thank you for contributing to DaemonEye! Your contributions help make the project better for everyone.