|
Some checks failed
CI / POS (WPF, Windows) (push) Waiting to run
CI / Backend (.NET 8) (push) Successful in 58s
CI / Web (React + Vite) (push) Successful in 34s
Docker API / Build + push API (push) Failing after 5s
Docker API / Deploy API on stage (push) Has been skipped
Docker Web / Build + push Web (push) Failing after 6s
Docker Web / Deploy Web on stage (push) Has been skipped
В предыдущей попытке 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> |
||
|---|---|---|
| .. | ||
| ci.yml | ||
| docker-api.yml | ||
| docker-web.yml | ||
| notify.yml | ||