nocr/flea
3
0
Fork 0
Code Issues 1 Pull Requests Packages Projects 1 Releases Wiki Activity

main commit fix.

Browse Source
This commit is contained in:
ruberoid 2025-10-16 17:15:27 +04:00
parent b2a4b8112d
commit 289ddaaea7
1 changed files with 64 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
CLAUDE.md
View File

@ -16,12 +16,16 @@ This is a microservices-based Telegram bot system for text monitoring and notifi
## Architecture
The services follow a message bus pattern using RabbitMQ for async communication:
- TelegramListener publishes MessageReceived events
- TextMatcher subscribes to MessageReceived, stores match history in database, and publishes:
- TelegramListener publishes:
- **MessageReceived** events (for new messages)
- **MessageEdited** events (for edited messages)
- TextMatcher subscribes to MessageReceived and MessageEdited, stores match history in database, and publishes:
- TextSubscriptionMatched events (for first-time matches)
- TextSubscriptionUpdated events (for updates to previously matched messages)
- TelegramClient subscribes to both TextSubscriptionMatched and TextSubscriptionUpdated events and notifies users
**Note:** WTelegram sends both `UpdateNewChannelMessage` and `UpdateEditChannelMessage` for the same message. TelegramListener publishes separate events to avoid duplicate notifications downstream.
Each service follows Clean Architecture with separate projects for:
- Host (API/entry point)
- AppServices (business logic)
@ -134,4 +138,61 @@ When running with docker-compose:
- Entity Framework Core with MariaDB
- WTelegramClient for Telegram API
- Rebus for message bus (RabbitMQ)
- Docker & Docker Compose for containerization
- Docker & Docker Compose for containerization
- Drone CI/CD on Kubernetes
## CI/CD Pipeline
**📖 See [_deploy/README.md](_deploy/README.md) for full CI/CD documentation.**
The project uses Drone CI with 5 specialized pipelines:
### 1. Feature Validation (`feature/*`, `fix/*` branches)
- Triggered on push to feature/fix branches
- Runs build + tests with Testcontainers support
- Provides fast feedback before merge
- Duration: ~3-5 minutes
### 2. Main Validation (`main` branch)
- Triggered on push to main
- Same checks as feature validation
- Ensures main branch stays healthy
- Duration: ~3-5 minutes
### 3. Contracts-Only Publish (tags with `contracts_only:`)
- Triggered by tag + commit message containing `contracts_only:<service>`
- Publishes NuGet contracts without building Docker images
- Fast iteration on contract changes
- Duration: ~2 minutes
- Example: `git commit -m "contracts_only:telegram_listener - Add MessageEdited event"`
### 4. Full Release (clean tags)
- Triggered by tag without special markers
- Complete release cycle:
1. Publish all NuGet contracts (parallel)
2. Build all Docker images with Kaniko (parallel, after contracts)
3. Deploy to Kubernetes (automatic for `v*` tags)
- Duration: ~8-10 minutes
- Example: `git tag v1.3.0`
### 5. Deploy-Only (tags with `deploy_only:`)
- Triggered by tag + commit message containing `deploy_only:`
- Skips building, only deploys existing images
- Useful for rollbacks and hotfixes
- Duration: ~1 minute
- Example: `git commit --allow-empty -m "deploy_only: Deploy v1.2.9"`
### Deployment Scripts
Located in `_deploy/scripts/`:
- **deploy.sh** - Deploy services to Kubernetes with health checks
- **rollback.sh** - Rollback deployments to previous version
- **health-check.sh** - Check health of all services
### Key Optimizations
- **Shared NuGet cache** across pipeline steps (~60% faster builds)
- **Parallel execution** for independent operations
- **Proper dependency order**: Contracts → Images → Deploy
- **Kaniko layer caching** for faster Docker builds
- **Docker-in-Docker** support for Testcontainers in tests