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>
