DenozordecandCursor
8c97445f7e
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]>
Gitea Actions
Workflow: workflows/ci.yaml.
| Job | PR | push в main |
|---|---|---|
| changes, openapi, web, go, bird2 | quality gates | quality gates |
| commitlint | да | — |
| release | — | semantic-release + docker push (один run) |
Подробнее: docs/releasing.md.
CI (quality gates)
Job changes вычисляет флаги по путям в diff. Полный прогон (все узлы openapi / web / go / bird2 в графе): .gitea/workflows/*, scripts/*, .golangci.yml, .pre-commit-config.yaml, корневой package.json / .releaserc.json. Отдельно: migrations/*, docs/openapi.yaml → go / openapi и т.д. (см. ci.yaml).
На pull request — commitlint (Conventional Commits).
Runner: ubuntu-latest, bird2 из apt, Docker для job release.
Release (job в ci.yaml)
После успешных quality gates на push в main job release:
npx semantic-release— тегvX.Y.Zна текущий commit (без дополнительного commit в main).- Gitea Release +
CHANGELOG.mdкак attachment (не в git). docker buildx bake default --pushсVERSION=X.Y.Z— в том же job.
Если releasable-коммитов нет — semantic-release no-op, образы не публикуются.
Секреты
ACTIONS_PAT: push tags, releases, Container Registry. Fallback: gitea.token.
Теги образов
git.shts.su/<owner>/<имя>:latest
git.shts.su/<owner>/<имя>:v1.2.3
git.shts.su/<owner>/<имя>:1.2.3
git.shts.su/<owner>/<имя>:<short-sha>
git.shts.su/<owner>/<имя>:sha-<full-sha>
Имена образов: evobgp-api, evobgp-all, evobgp-scheduler, evobgp-ingest, evobgp-render, evobgp-deploy, evobgp-node, evobgp-web, evobgp-web-all, evobgp-agent, evobgp-bird2.
Удалённый спикер (compose deploy/compose/docker-compose.remote-speaker.yaml): evobgp-bird2, evobgp-agent, evobgp-node (fallback profile); Traefik — внешний traefik:latest. CI: scripts/validate-remote-speaker-compose.sh.
Пример:
docker pull git.shts.su/myuser/evobgp-api:1.2.3