Sprint 16 — постоянный regression-контур: flows + visual + nightly +
CI workflow + README badges.
Ключевые цифры:
- 35 flow-тестов: 35/35 ✓ за ~30 секунд (workers=2 локально).
- 60 visual snapshot'ов (15 страниц × 2 темы × 2 viewport'a):
60/60 ✓ за ~4 минуты с retries=1.
- Полный регресс прогон: ~5 минут (цель была < 15).
Что сделано:
1. tests/regression/ — Playwright + factories + 8 spec-файлов.
OrgFactory builder создаёт org через API за O(N) HTTP вызовов
(signup → token → refs → products → counterparties → posted supplies).
Каждый flow независим, использует свой fresh-org.
2. tests/regression/visual/ — 15 страниц × 2 темы × 2 viewport'a.
Маски на динамический контент (артикулы с Date.now, KPI'ы,
delta-стрелки) чтобы 0.2% threshold не флакал. snapshotPathTemplate
c {projectName} — desktop+mobile не затирают друг друга.
3. tests/regression/factories/OrgFactory.ts — builder с .withProducts
.withCounterparties .withSupplies. Retry signup'a на 429.
4. .forgejo/workflows/regression.yml — on workflow_run после
Docker API/Web; cache на pnpm-store + Playwright-browsers;
артефакты при failure; Telegram-уведомление в обоих случаях.
5. ~/nightly-verify.sh + cron `0 4 * * *`: health → redeploy если
нужно → smoke flows; в воскресенье полный flows+visual. Логи с
ротацией 14 дней. Telegram на провал (~/.fm-watchdog/telegram-*).
6. scripts/generate-badges.sh — coverage из cobertura.xml в SVG через
shields.io (offline fallback). 4 CI-status badge + coverage badge в
README; CI step «Update coverage badge» авто-коммитит обновлённый
SVG на push в main.
Локальное число flake'ов: 1/60 visual на retry=1 (product-new light) —
случайная гонка маски, retry'ит и проходит.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Корень бага «кнопка Войти ведёт на zat.kz/410-Gone»:
.forgejo/workflows/docker-public.yml хардкодил PUBLIC_SITE_URL и
PUBLIC_APP_URL на zat.kz. На каждый git push CI собирал docker-image
с zat.kz и пушил под :latest, перетирая мои локальные пересборки.
Контейнер вечно крутил stale-бандл с href Войти=zat.kz/login.
Чиню env workflow:
- PUBLIC_SITE_URL → https://test.food-market.kz
- PUBLIC_APP_URL → https://admin.food-market.kz
- TG-нотификация о деплое — ссылка на test.food-market.kz.
Локально форсировал свежий image (--no-cache), push под :latest,
compose pull --force-recreate. Smoke на проде:
- href Войти → https://admin.food-market.kz/login
- Никаких zat.kz в /usr/share/nginx/html (grep пуст).
Доменная схема (по решению юзера):
food-market.zat.kz → новый Astro public-сайт (порт 8082, контейнер food-market-public)
app.food-market.zat.kz → существующая админка (food-market.web, порт 8081)
API остаётся на app.* под /api/*.
Изменения:
- docker-compose: добавлен сервис public (image food-market-public:latest,
127.0.0.1:8082:80). На стенде .env дополнен PUBLIC_TAG=latest, контейнер
поднят, smoke на / и /pricing проходит.
- Forgejo workflow .forgejo/workflows/docker-public.yml — отдельный билд
при изменениях в src/food-market.public/**: docker build с
--build-arg PUBLIC_SITE_URL=https://food-market.zat.kz и
--build-arg PUBLIC_APP_URL=https://app.food-market.zat.kz, push в
локальный registry, deploy через docker compose pull+up. TG-пинг.
- Nginx (на стенде вручную, не через репо):
- Новый блок food-market-app.conf для app.food-market.zat.kz —
проксирует на :8081 (web), вместе с /api/admin/import/ и
/tg-webhook путями. Certbot --nginx выпустил SSL.
- Старый food-market-stage.conf переписан на public — проксирует на
:8082, использует существующий SSL для food-market.zat.kz.
- API CORS: добавлены food-market.zat.kz, app.food-market.zat.kz,
food-market.kz, app.food-market.kz в AllowedOrigins (publicу нужен
food-market.zat.kz для signup-запросов, админке нужен app.*).
- JWT cookie domain не настраиваем — проект использует localStorage,
cross-domain auth-bridge через URL fragment (см. AuthBridgePage),
что безопаснее cookie с .food-market.zat.kz.
- Хардкодов food-market.zat.kz в food-market.web/src не нашлось —
всё через относительные URL.
Существующие админ-сессии: токены в localStorage привязаны к
food-market.zat.kz origin. После переезда юзеры увидят на этом
домене публичный сайт без своих токенов — нужно перелогиниться
на app.food-market.zat.kz.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
buildx --driver docker-container запускает builder в изолированном
сетевом namespace, откуда 127.0.0.1:5001 (host registry) недоступен:
ошибка «dial tcp 127.0.0.1:5001: connect: connection refused» в шаге
FROM ${LOCAL_REGISTRY}/mirror/dotnet-aspnet:8.0.
Откатываю на классический `docker build` + `docker push`. У host
docker daemon уже есть 127.0.0.1:5001 в insecure-registries, layer-cache
демона между сборками сохраняет dotnet restore / pnpm install при
стабильных манифестах. Path-фильтры (api vs web) остаются — это
основной выигрыш по времени.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
В предыдущей попытке runner v6.2.2 не подружился с cross-job outputs —
job changes падал «'runs-on' key not defined in Docker Images/changes»
и оба следующих job уходили в skipped. Откатываю на надёжный путь:
два отдельных workflow с paths-фильтром на уровне триггера.
- docker-api.yml: триггерится на src/food-market.api/**,
application/**, domain/**, infrastructure/**, shared/**, sln,
Dockerfile.api, compose. Билдит buildx с registry-cache, пуллит
и пересоздаёт ТОЛЬКО api (`docker compose up -d --no-deps api`).
- docker-web.yml: триггерится на src/food-market.web/**, Dockerfile.web,
nginx.conf, compose. Делает то же для web.
- .env стенда теперь идемпотентный — оба тэга всегда :latest, после
push образа buildx обновляет latest, pull тянет свежий.
- Telegram отдельные сообщения «stage api deployed» / «stage web
deployed» с SHA — понятно что именно прилетело.
Push, который не задевает ни api/ ни web/ исходники (только md/docs),
вообще не запускает workflow — экономия очевидна.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Цель: типичный push должен катиться за 30-60 сек вместо 3-5 мин.
docker.yml — две оптимизации:
1. Job changes детектит что изменилось (api/web) через `git diff
HEAD~1 HEAD`. Образ пересобирается только если затронуты его
директории; `paths-ignore` отсекает docs/*.md/.github/**.
2. Сборка через `docker buildx build` с registry-cache:
--cache-from / --cache-to type=registry,ref=...:buildcache,mode=max.
Локальный 127.0.0.1:5001 уже разрешает DELETE, так что mutable
buildcache работает. dotnet restore / pnpm install теперь почти
мгновенные при отсутствии изменений в *.csproj / pnpm-lock.yaml.
3. deploy-stage запускается только если api или web реально
пересобирался; для пропущенного образа в .env пишется :latest,
compose pull тянет последний успешный slim. Telegram-сообщение
указывает что именно деплоилось ([api web] / [web] / только compose).
ci.yml — actions/cache для NuGet (~/.nuget/packages по hash *.csproj)
и pnpm store (по hash pnpm-lock.yaml). paths-ignore такое же.
POS-job (windows-latest) не трогаем — он и так fires только на
тег v* / workflow_dispatch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
pack8-ping.yml #64 отработал (Telegram уведомление отправлено),
одноразовый workflow больше не нужен.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Триггерится только при изменении самого файла — после выполнения
будет удалён следующим коммитом.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Any block on mcr.microsoft.com or docker.io from KZ would stall our
builds. Mirror docker base images into 127.0.0.1:5001 under mirror/*
via daily systemd timer, and point Dockerfiles + compose + CI at the
local copies.
Mirror:
node:20-alpine → 127.0.0.1:5001/mirror/node:20-alpine
nginx:1.27-alpine → 127.0.0.1:5001/mirror/nginx:1.27-alpine
postgres:16-alpine → 127.0.0.1:5001/mirror/postgres:16-alpine
mcr.microsoft.com/dotnet/sdk:8.0 → 127.0.0.1:5001/mirror/dotnet-sdk:8.0
mcr.microsoft.com/dotnet/aspnet:8.0 → 127.0.0.1:5001/mirror/dotnet-aspnet:8.0
Infra (committed for reproducibility):
- deploy/mirror-base-images.sh — pull/tag/push (idempotent)
- deploy/food-market-mirror-base-images.{service,timer} — daily refresh,
installed on stage server
Usage in build-time:
- Dockerfile.api/web take ARG LOCAL_REGISTRY=127.0.0.1:5001 with the local
copy as default, so the same Dockerfile still builds from docker.io if
you pass --build-arg LOCAL_REGISTRY=docker.io (well, almost).
- docker-compose.yml postgres: image via ${REGISTRY}/mirror/postgres.
- ci.yml postgres service container: local mirror.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Main расходился с БД стейджа (Phase2c3_MsStrict в history, но код ещё ссылался на VatRate etc.) — деплой ломался. Реплицирую удаление сущностей вручную, чтобы код совпадал с таблицами.
Убрано (нет в OtherSystem — не выдумываем):
- Domain: VatRate сущность целиком; Counterparty.Kind + enum CounterpartyKind; Store.Kind + enum StoreKind; Product.IsAlcohol; UnitOfMeasure.Symbol/DecimalPlaces/IsBase.
- EF: DbSet<VatRate>, ConfigureVatRate, Product.VatRate navigation, индекс Counterparty.Kind.
- DTO/Input: соответствующие поля и VatRateDto/Input.
- API: VatRatesController удалён; references в Products/Counterparties/Stores/UoM/Supplies/Retail/Stock.
Добавлено как в OtherSystem:
- Product.Vat (int) + Product.VatEnabled — OtherSystem держит НДС числом на товаре.
- KZ default VAT 16% — applied в сидерах и в OtherSystemImportService когда товар не принёс свой vat.
OtherSystemImportService:
- ResolveKind убран; CompanyType=entrepreneur→Individual (как и было).
- VatRates lookup → прямой p.Vat ?? 16 + p.Vat > 0 для VatEnabled.
- baseUnit ищется по code="796" вместо IsBase.
Web:
- types.ts: убраны CounterpartyKind/StoreKind/VatRate/Product.vatRateId/vatPercent/isAlcohol/UoM.symbol/decimalPlaces/isBase; добавлено Product.vat/vatEnabled; унифицировано unitSymbol→unitName.
- VatRatesPage удалён, роут из App.tsx тоже.
- CounterpartiesPage/StoresPage/UnitsOfMeasurePage: убраны соответствующие поля в формах.
- ProductEditPage: select "Ставка НДС" теперь с фиксированными 0/10/12/16/20 + чекбокс VatEnabled.
- Stock/RetailSale/Supply pages: unitSymbol → unitName.
deploy-stage unguarded — теперь код соответствует DB, авто-deploy безопасен.
The stage DB is on Phase2c3_MsStrict (vat_rates dropped, etc.), but
main still has Product.VatRateId / DbSet<VatRate> and friends — that
code would blow up at startup against the current DB. The user's
'feat strict OtherSystem schema' commit (f7087e9) isn't present in main
any more (looks like a rebase dropped it); the pre-built image with
that SHA is still in the registry and that's what the stage is pinned
to right now.
Until main gets the matching code, deploy-stage should only fire on
tag or manual dispatch — push-to-main still builds images, just
doesn't roll the stage forward.
Forgejo Actions doesn't reliably trigger a separate workflow on
`workflow_run: Docker Images succeeded` (at least on 7.0.16), so the
stage deploy would never fire. Merging the deploy step into the same
docker workflow as a dependent job keeps it atomic: build api, build
web, then (needs: [api, web]) deploy + smoke + telegram ping.
Forgejo Actions synthesizes a GITHUB_TOKEN for the Forgejo API, not
github.com. Using it to docker-login to ghcr.io always fails (401).
Forgejo side is the new primary — push to the local registry only.
ghcr.io mirroring, if ever wanted, will go through a separate job with
an explicit GitHub PAT in GHCR_TOKEN secret.
code.forgejo.org does not mirror actions/setup-dotnet — the Forgejo
runner was failing at 'workflow prepared' with 'Unauthorized' trying
to clone it. Rather than fork a bunch of actions, install the tooling
directly on the runner host (apt dotnet-sdk-8.0, nodesource node 20,
npm -g pnpm) and call dotnet/node/pnpm inline. This keeps CI fully
independent from external action registries.
GitHub Actions copy in .github/workflows still uses the stock actions
(and the cloud-backed setup-dotnet); it will be disabled in a follow-up
once the Forgejo run is green end-to-end.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Forgejo Actions runner on the stage server picks up these jobs. Runs on
the same labels `[self-hosted, linux]` — same self-hosted box as the
Docker registry and the stage itself.
deploy-stage is simplified: no SSH round-trip (runner and stage are the
same host), just `cp` + `docker compose pull/up`.
POS job kept as-is; it's gated on tag/dispatch and a Windows runner, so
on Forgejo it'll simply not match any runner and stay queued — that's
fine, POS ships from tags only.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
