DenozordecandCursor
8c97445f7e
CI / changes (push) Successful in 12s
CI / openapi (push) Has been skipped
CI / web (push) Has been skipped
CI / commitlint (push) Has been skipped
CI / go (push) Successful in 1m11s
CI / bird2 (push) Successful in 16s
CI / release (push) Successful in 4m27s
TestParallelModuleRefresh_CoalescesDeployApply падал на CI под -race (want exactly one deploy_apply job, got 2). Локально тест проходил стабильно (100/500 итераций с -cpu), но узкая гонка проявлялась при замедлении под race-детектором. Корень: коалесцирование решало «делать ли deploy» через CountOtherActiveRefresh, который опрашивал статусы job-ов (queued/ running). Статусы меняются асинхронно относительно tenantRefreshMu, поэтому в редких таймингах оба параллельных refresh могли решить, что другой уже не активен, и каждый породил свой deploy_apply. Решение — детерминированный inflight-счётчик refresh-kind job-ов в Registry (inflightRefresh map[string]int), управляемый под r.mu: - инкремент в Enqueue при создании нового refresh-kind job-а; - декремент + проверка «последний ли я» в finishModuleRefreshSuccess через новый метод finalizeRefreshCoalesce (под tenantRefreshMu). Последний refresh (счётчик <= 1) делает render + deploy_apply; все остальные defer-ят. Решение больше не зависит от опроса статусов и таймингов ingest. Чтобы счётчик не утёк на error/cancel путях (где refresh не доходит до finishModuleRefreshSuccess), обработка module_refresh и tenant_refresh вынесена в runModuleRefresh / runTenantRefresh с defer-обёрткой, которая гарантированно освобождает слот, если finishModuleRefreshSuccess не отработал. CountOtherActiveRefresh / CountOtherActiveModuleRefresh оставлены как публичные методы (могут использоваться в мониторинге); из продакшн-логики коалесцирования убраны. Проверки: go build, go vet, go test ./internal/... -count=1 — exit 0. Стресс-тест коалесцирования: 200 итераций с -cpu=4 — стабильно. Co-authored-by: Cursor <[email protected]>
EvoBGP
Control plane для управления префиксами, модулями ingest, ревизиями конфигурации BIRD и выкладкой на BGP-спикеры. Репозиторий включает HTTP API на Go, веб-интерфейс (web/), CLI для реплик (evobgp-node), агент и Docker Compose для локального и эталонного развёртывания.
Документация
| Документ | Содержание |
|---|---|
| AGENTS.md | Краткая карта репозитория и советы для ИИ-агентов (экономия контекста) |
| docs/README.md | Оглавление и навигация по разделам |
| docs/overview.md | Ключевые возможности продукта |
| docs/quickstart.md | Быстрый запуск (Docker, локально, фронтенд) |
| docs/architecture.md | Архитектура компонентов и потоков данных |
| docs/api.md | Как работать с REST API и OpenAPI |
| docs/access.md | API-ключи, роли, нода, CORS, безопасность |
Контракт HTTP API: docs/openapi.yaml. Человекочитаемый просмотр: docs/openapi.html (см. docs/OPENAPI-GITEA.md).
Быстрый старт (Docker)
Из каталога deploy/compose (PowerShell):
cd deploy\compose
Copy-Item .env.example .env -Force # EVOBGP_REGISTRY=git.shts.su/<owner>
docker login git.shts.su
docker compose --profile microvps pull
docker compose --profile microvps up -d
Профиль microvps поднимает evobgp-all, PostgreSQL, BIRD2 и агент (образы из Container Registry, без --build). API по умолчанию: http://localhost:8080.
Эталонный стек (несколько сервисов, NATS, веб UI, Prometheus):
docker compose --profile reference pull
docker compose --profile reference up -d
Подробности портов и переменных окружения — в docs/quickstart.md и в комментариях в deploy/compose/docker-compose.yaml.
Разработка
- Go: модуль
evobgp, точки входа вcmd/. - Веб: SvelteKit в каталоге
web/(см. web/README.md).
Версионирование и релизы
Версии определяются автоматически из Conventional Commits при merge в main (semantic-release на Gitea Actions). Первая версия — 1.0.0; ручной bump не нужен.
- docs/releasing.md — пайплайн, commit conventions, секреты CI
- API:
GET /versionиGET /v1/version(полеversion) - Docker-образы: теги
latest,vX.Y.Z,X.Y.Z— в том же CI run, что и релиз (jobrelease)
Лицензия и условия использования — по политике владельца репозитория.