Remove .serena folder from tracking and add to .gitignore
This commit is contained in:
parent
0c06e159bb
commit
b150e08163
3
.gitignore
vendored
3
.gitignore
vendored
|
@ -63,3 +63,6 @@ debug_*.sql
|
|||
|
||||
# Service files
|
||||
*.service
|
||||
|
||||
# Serena AI assistant files
|
||||
.serena/
|
||||
|
|
Binary file not shown.
|
@ -1,82 +0,0 @@
|
|||
# Church API Code Style & Conventions
|
||||
|
||||
## Rust Code Style
|
||||
|
||||
### Naming Conventions
|
||||
- **Functions**: `snake_case` (e.g., `get_video_duration_direct`, `transcode_hls_segment_ffmpeg`)
|
||||
- **Types/Structs**: `PascalCase` (e.g., `StreamingTranscodingService`, `ChunkStreamingService`)
|
||||
- **Constants**: `SCREAMING_SNAKE_CASE` (e.g., `TS_PACKET_SIZE`, `NUM_PACKETS`)
|
||||
- **Variables**: `snake_case` (e.g., `source_path`, `media_item_id`)
|
||||
- **Modules**: `snake_case` (e.g., `streaming_transcoding`, `chunk_streaming`)
|
||||
|
||||
### File Organization
|
||||
- **Handlers**: `src/handlers/*.rs` - HTTP request handling
|
||||
- **Services**: `src/services/*.rs` - Business logic layer
|
||||
- **Models**: `src/models/*.rs` - Data models and database entities
|
||||
- **Utils**: `src/utils/*.rs` - Shared utility functions
|
||||
- **DB**: `src/db/*.rs` - Database access layer
|
||||
|
||||
### Error Handling
|
||||
- Uses custom `ApiError` type with `Result<T>` return type
|
||||
- Comprehensive error mapping with `.map_err()` for external errors
|
||||
- Structured error messages with context
|
||||
|
||||
### Logging Style
|
||||
```rust
|
||||
// Informational with emoji indicators
|
||||
tracing::info!("🚀 Using CLI ffmpeg with Intel QSV AV1 hardware decoding");
|
||||
tracing::info!("✅ Segment {} transcoded successfully", segment_index);
|
||||
|
||||
// Warnings
|
||||
tracing::warn!("⚠️ Creating placeholder segment {}", segment_index);
|
||||
|
||||
// Errors
|
||||
tracing::error!("❌ Failed to transcode segment {}: {:?}", segment_index, e);
|
||||
|
||||
// Debug information
|
||||
tracing::debug!("🎬 FFmpeg command: {:?}", cmd);
|
||||
```
|
||||
|
||||
### Async/Await Patterns
|
||||
- Extensive use of `async`/`await` with Tokio runtime
|
||||
- Proper error propagation with `?` operator
|
||||
- Background task spawning with `tokio::spawn()`
|
||||
|
||||
### Documentation
|
||||
- Function-level documentation for public APIs
|
||||
- Inline comments for complex logic
|
||||
- TODO comments for known improvements needed
|
||||
|
||||
## Architecture Patterns
|
||||
|
||||
### Service Layer Pattern
|
||||
- Services handle business logic
|
||||
- Handlers are thin and focus on HTTP concerns only
|
||||
- Clear separation between web layer and business logic
|
||||
|
||||
### Error Handling Strategy
|
||||
```rust
|
||||
// Convert external errors to ApiError
|
||||
.map_err(|e| ApiError::Internal(format!("Failed to run ffmpeg: {}", e)))?
|
||||
```
|
||||
|
||||
### Resource Management
|
||||
- Use of `Arc<RwLock<>>` for shared mutable state
|
||||
- Semaphores for limiting concurrent operations
|
||||
- Proper cleanup in GStreamer pipelines
|
||||
|
||||
### Configuration
|
||||
- Environment variables used extensively (`std::env::var`)
|
||||
- Sensible defaults provided
|
||||
- Hardware acceleration detection and fallbacks
|
||||
|
||||
## Performance Considerations
|
||||
- Hardware acceleration preferred (VA-API, Intel QSV)
|
||||
- Chunked/streaming processing for large media files
|
||||
- Caching of transcoded segments
|
||||
- Concurrent processing limits to prevent resource exhaustion
|
||||
|
||||
## Dependencies Management
|
||||
- Clear separation of concerns in Cargo.toml
|
||||
- Comments explaining dependency purposes
|
||||
- Both FFmpeg and GStreamer maintained during transition period
|
|
@ -1,41 +0,0 @@
|
|||
# Church API Project Overview
|
||||
|
||||
## Purpose
|
||||
The Church API is a Rust-based web service designed for church media management and streaming. The primary functionality includes:
|
||||
|
||||
- **Media Management**: Upload, organize, and manage church sermons and media content
|
||||
- **Video Streaming**: Provide intelligent video streaming with adaptive codec support (AV1, HEVC, H.264)
|
||||
- **User Authentication**: JWT-based authentication system
|
||||
- **Database Integration**: PostgreSQL database with SQLx for data persistence
|
||||
- **Email Services**: Automated email functionality for church communications
|
||||
|
||||
## Tech Stack
|
||||
- **Language**: Rust (2021 edition)
|
||||
- **Web Framework**: Axum 0.7 with async/await (Tokio runtime)
|
||||
- **Database**: PostgreSQL with SQLx 0.7
|
||||
- **Media Processing**:
|
||||
- GStreamer bindings (0.22) for high-performance streaming
|
||||
- FFmpeg bindings (ffmpeg-next 7.0) - being replaced with GStreamer
|
||||
- **Authentication**: JWT (jsonwebtoken) + bcrypt for password hashing
|
||||
- **Logging**: tracing + tracing-subscriber for structured logging
|
||||
- **Testing**: Built-in Rust testing framework
|
||||
|
||||
## Key Features
|
||||
1. **Smart Video Streaming**: Detects client capabilities and serves optimal codec (AV1 direct, HEVC, or H.264 with transcoding)
|
||||
2. **Hardware Acceleration**: Uses Intel QSV and VA-API for efficient video processing
|
||||
3. **Chunk-based Streaming**: Netflix-style 10-second segments for smooth playback
|
||||
4. **Caching System**: Intelligent caching of transcoded video segments
|
||||
5. **HLS Support**: HTTP Live Streaming for maximum compatibility
|
||||
|
||||
## Architecture
|
||||
- **Services Layer**: Business logic for transcoding, streaming, media scanning
|
||||
- **Handlers Layer**: HTTP request handlers using Axum
|
||||
- **Models Layer**: Data models and database entities
|
||||
- **Utils Layer**: Shared utilities (codec detection, validation, etc.)
|
||||
|
||||
## Current Performance Focus
|
||||
The project is actively migrating from FFmpeg CLI calls to native GStreamer bindings to:
|
||||
- Eliminate subprocess overhead
|
||||
- Reduce buffering and latency
|
||||
- Improve hardware acceleration utilization
|
||||
- Enable better error handling and resource management
|
|
@ -1,114 +0,0 @@
|
|||
# Church API Development Commands
|
||||
|
||||
## Core Development Commands
|
||||
|
||||
### Building & Testing
|
||||
```bash
|
||||
# Build the project
|
||||
cargo build
|
||||
|
||||
# Build with release optimizations
|
||||
cargo build --release
|
||||
|
||||
# Run tests
|
||||
cargo test
|
||||
|
||||
# Run specific test module with output
|
||||
cargo test images::tests -- --nocapture
|
||||
|
||||
# Check code without building
|
||||
cargo check
|
||||
|
||||
# Format code
|
||||
cargo fmt
|
||||
|
||||
# Run clippy linter
|
||||
cargo clippy
|
||||
```
|
||||
|
||||
### Running the Application
|
||||
```bash
|
||||
# Run in development mode (from src/main.rs)
|
||||
cargo run
|
||||
|
||||
# Run the named binary
|
||||
cargo run --bin church-api
|
||||
|
||||
# Run with environment variables
|
||||
RUST_LOG=debug cargo run
|
||||
```
|
||||
|
||||
### Database Management
|
||||
```bash
|
||||
# The project uses SQLx with PostgreSQL
|
||||
# Migration files are likely in the migrations/ directory
|
||||
# Check for database setup in .env files
|
||||
```
|
||||
|
||||
### System Integration
|
||||
```bash
|
||||
# The project includes systemd service management
|
||||
sudo systemctl restart church-api
|
||||
sudo systemctl status church-api
|
||||
|
||||
# Logs can be viewed with
|
||||
journalctl -fu church-api
|
||||
```
|
||||
|
||||
### Media Processing
|
||||
```bash
|
||||
# The project uses both FFmpeg and GStreamer
|
||||
# Check Intel Media Stack environment:
|
||||
export LIBVA_DRIVER_NAME=iHD
|
||||
export LIBVA_DRIVERS_PATH=/opt/intel/media/lib64
|
||||
|
||||
# Check hardware acceleration support
|
||||
vainfo
|
||||
intel_gpu_top
|
||||
```
|
||||
|
||||
### Testing & Debugging Scripts
|
||||
```bash
|
||||
# Various test scripts are available:
|
||||
./test.sh # General testing
|
||||
./test_images.sh # Image processing tests
|
||||
./test_media_system.sh # Media system tests
|
||||
./comprehensive_test.sh # Full system tests
|
||||
./server_debug.sh # Server debugging
|
||||
|
||||
# Church-specific scripts:
|
||||
./church-api-script.sh # API management
|
||||
./bible_verse.sh # Bible verse functionality
|
||||
```
|
||||
|
||||
### File System Organization
|
||||
```bash
|
||||
# Uploads directory
|
||||
ls -la uploads/
|
||||
|
||||
# Configuration
|
||||
cat .env
|
||||
cat .env.example
|
||||
|
||||
# Service files
|
||||
ls -la *.service
|
||||
|
||||
# Migration and backup files
|
||||
ls -la migrations/
|
||||
ls -la backup_before_*/
|
||||
```
|
||||
|
||||
### Development Workflow
|
||||
1. Make changes to code
|
||||
2. Run `cargo check` for quick syntax validation
|
||||
3. Run `cargo test` to ensure tests pass
|
||||
4. Run `cargo build` to compile
|
||||
5. Test with relevant `test_*.sh` scripts
|
||||
6. Deploy with `sudo systemctl restart church-api`
|
||||
|
||||
## Key Directories
|
||||
- `src/` - Rust source code
|
||||
- `migrations/` - Database migrations
|
||||
- `uploads/` - Media file storage
|
||||
- `templates/` - HTML templates
|
||||
- `tests/` - Test files
|
|
@ -1,108 +0,0 @@
|
|||
# Task Completion Workflow
|
||||
|
||||
## When a coding task is completed, follow these steps:
|
||||
|
||||
### 1. Code Quality Checks
|
||||
```bash
|
||||
# Format the code
|
||||
cargo fmt
|
||||
|
||||
# Run linter
|
||||
cargo clippy
|
||||
|
||||
# Check for compilation errors
|
||||
cargo check
|
||||
```
|
||||
|
||||
### 2. Build & Test
|
||||
```bash
|
||||
# Build the project
|
||||
cargo build
|
||||
|
||||
# Run tests
|
||||
cargo test
|
||||
|
||||
# Run specific tests if relevant
|
||||
cargo test module_name -- --nocapture
|
||||
```
|
||||
|
||||
### 3. Media System Testing (if relevant)
|
||||
```bash
|
||||
# Test media processing
|
||||
./test_media_system.sh
|
||||
|
||||
# Test image processing (if modified)
|
||||
./test_images.sh
|
||||
|
||||
# Run comprehensive tests
|
||||
./comprehensive_test.sh
|
||||
```
|
||||
|
||||
### 4. Service Integration Testing
|
||||
```bash
|
||||
# Restart the service
|
||||
sudo systemctl restart church-api
|
||||
|
||||
# Check service status
|
||||
sudo systemctl status church-api
|
||||
|
||||
# View logs for errors
|
||||
journalctl -fu church-api --lines=50
|
||||
```
|
||||
|
||||
### 5. API Testing (if relevant)
|
||||
```bash
|
||||
# Test authentication
|
||||
curl -X POST https://api.rockvilletollandsda.church/api/auth/login \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"username": "admin", "password": "..."}'
|
||||
|
||||
# Test relevant endpoints with JWT token
|
||||
# (Check fix_routes.sh for examples)
|
||||
```
|
||||
|
||||
### 6. Performance Validation (for media changes)
|
||||
- Check hardware acceleration is working:
|
||||
```bash
|
||||
vainfo
|
||||
intel_gpu_top # During transcoding
|
||||
```
|
||||
- Monitor memory usage and CPU utilization
|
||||
- Verify transcoding times are reasonable
|
||||
- Check for memory leaks in long-running operations
|
||||
|
||||
### 7. Documentation Updates
|
||||
- Update inline comments for complex changes
|
||||
- Add tracing logs for new operations
|
||||
- Update memory files if architecture changes
|
||||
|
||||
### 8. Final Checklist
|
||||
- [ ] Code compiles without warnings
|
||||
- [ ] Tests pass
|
||||
- [ ] Service restarts successfully
|
||||
- [ ] No memory leaks or resource exhaustion
|
||||
- [ ] Hardware acceleration functional (if applicable)
|
||||
- [ ] Logging provides adequate debugging information
|
||||
- [ ] Error handling is comprehensive
|
||||
|
||||
## Critical Notes
|
||||
|
||||
### For Media/Streaming Changes:
|
||||
- Always test with actual video files
|
||||
- Verify both AV1 and H.264 codecs work
|
||||
- Check HLS playlist generation
|
||||
- Test with different client user agents
|
||||
- Monitor segment caching behavior
|
||||
|
||||
### For GStreamer Integration:
|
||||
- Ensure GStreamer initialization succeeds
|
||||
- Test pipeline cleanup (no resource leaks)
|
||||
- Verify hardware acceleration paths
|
||||
- Check error handling for missing plugins
|
||||
- Test with various input formats
|
||||
|
||||
### Performance Requirements:
|
||||
- Transcoding should complete faster than real-time
|
||||
- Memory usage should remain stable
|
||||
- No blocking of other requests during transcoding
|
||||
- Proper cleanup of temporary files and resources
|
|
@ -1,68 +0,0 @@
|
|||
# language of the project (csharp, python, rust, java, typescript, go, cpp, or ruby)
|
||||
# * For C, use cpp
|
||||
# * For JavaScript, use typescript
|
||||
# Special requirements:
|
||||
# * csharp: Requires the presence of a .sln file in the project folder.
|
||||
language: rust
|
||||
|
||||
# whether to use the project's gitignore file to ignore files
|
||||
# Added on 2025-04-07
|
||||
ignore_all_files_in_gitignore: true
|
||||
# list of additional paths to ignore
|
||||
# same syntax as gitignore, so you can use * and **
|
||||
# Was previously called `ignored_dirs`, please update your config if you are using that.
|
||||
# Added (renamed)on 2025-04-07
|
||||
ignored_paths: []
|
||||
|
||||
# whether the project is in read-only mode
|
||||
# If set to true, all editing tools will be disabled and attempts to use them will result in an error
|
||||
# Added on 2025-04-18
|
||||
read_only: false
|
||||
|
||||
|
||||
# list of tool names to exclude. We recommend not excluding any tools, see the readme for more details.
|
||||
# Below is the complete list of tools for convenience.
|
||||
# To make sure you have the latest list of tools, and to view their descriptions,
|
||||
# execute `uv run scripts/print_tool_overview.py`.
|
||||
#
|
||||
# * `activate_project`: Activates a project by name.
|
||||
# * `check_onboarding_performed`: Checks whether project onboarding was already performed.
|
||||
# * `create_text_file`: Creates/overwrites a file in the project directory.
|
||||
# * `delete_lines`: Deletes a range of lines within a file.
|
||||
# * `delete_memory`: Deletes a memory from Serena's project-specific memory store.
|
||||
# * `execute_shell_command`: Executes a shell command.
|
||||
# * `find_referencing_code_snippets`: Finds code snippets in which the symbol at the given location is referenced.
|
||||
# * `find_referencing_symbols`: Finds symbols that reference the symbol at the given location (optionally filtered by type).
|
||||
# * `find_symbol`: Performs a global (or local) search for symbols with/containing a given name/substring (optionally filtered by type).
|
||||
# * `get_current_config`: Prints the current configuration of the agent, including the active and available projects, tools, contexts, and modes.
|
||||
# * `get_symbols_overview`: Gets an overview of the top-level symbols defined in a given file or directory.
|
||||
# * `initial_instructions`: Gets the initial instructions for the current project.
|
||||
# Should only be used in settings where the system prompt cannot be set,
|
||||
# e.g. in clients you have no control over, like Claude Desktop.
|
||||
# * `insert_after_symbol`: Inserts content after the end of the definition of a given symbol.
|
||||
# * `insert_at_line`: Inserts content at a given line in a file.
|
||||
# * `insert_before_symbol`: Inserts content before the beginning of the definition of a given symbol.
|
||||
# * `list_dir`: Lists files and directories in the given directory (optionally with recursion).
|
||||
# * `list_memories`: Lists memories in Serena's project-specific memory store.
|
||||
# * `onboarding`: Performs onboarding (identifying the project structure and essential tasks, e.g. for testing or building).
|
||||
# * `prepare_for_new_conversation`: Provides instructions for preparing for a new conversation (in order to continue with the necessary context).
|
||||
# * `read_file`: Reads a file within the project directory.
|
||||
# * `read_memory`: Reads the memory with the given name from Serena's project-specific memory store.
|
||||
# * `remove_project`: Removes a project from the Serena configuration.
|
||||
# * `replace_lines`: Replaces a range of lines within a file with new content.
|
||||
# * `replace_symbol_body`: Replaces the full definition of a symbol.
|
||||
# * `restart_language_server`: Restarts the language server, may be necessary when edits not through Serena happen.
|
||||
# * `search_for_pattern`: Performs a search for a pattern in the project.
|
||||
# * `summarize_changes`: Provides instructions for summarizing the changes made to the codebase.
|
||||
# * `switch_modes`: Activates modes by providing a list of their names
|
||||
# * `think_about_collected_information`: Thinking tool for pondering the completeness of collected information.
|
||||
# * `think_about_task_adherence`: Thinking tool for determining whether the agent is still on track with the current task.
|
||||
# * `think_about_whether_you_are_done`: Thinking tool for determining whether the task is truly completed.
|
||||
# * `write_memory`: Writes a named memory (for future reference) to Serena's project-specific memory store.
|
||||
excluded_tools: []
|
||||
|
||||
# initial prompt for the project. It will always be given to the LLM upon activating the project
|
||||
# (contrary to the memories, which are loaded on demand).
|
||||
initial_prompt: ""
|
||||
|
||||
project_name: "church-api"
|
Loading…
Reference in a new issue