admin/.tasks/vehicles-loader-progress-deploy.md

vehicles-loader-progress-deploy

Goal

Доставить @stostayer/vehicles-loader 0.4.0 (прогресс-логирование) на прод клиента и верифицировать, что journalctl во время боевого sync показывает движение, а не ~2ч тишины.

Код-сайд готов: progress-logging зашипан в stostayer.new master (commit a74ef73, bump 0.3.0 → 0.4.0, 24/24 теста зелёные). Это чисто ops-handoff: rebuild образа на той же схеме, что и 0.3.0 (build здесь → push в registry клиента docker.stostayer.ru → host pull + re-tag), затем дождаться/прогнать sync и снять лог.

Закрывает единственный не-верифицированный acceptance-критерий исходной таски stostayer.new/.tasks/vehicles-loader-progress-logging.md — «journalctl показывает движение» (остальные 4/5 покрыты unit-тестами; этот по природе требует живого прод-прогона).

Что нового в 0.4.0 (что должно появиться в логе)

• Фазовые строки: ▶ <phase> — start / ✓ <phase> — done: N rows, <dur> для branches / vehicles / units / delete-sweep.
• Батч-прогресс: manufacturers: 18/183 (12s), units: 5/26 (…) — авто-шаг ≈ total/10.
• delete-sweep per-model: delete-sweep <model>: N disabled / 0 — выгрузка полная / skip (пустой seen-set).

Pending ops actions

• Build & push на dev-машине из корня stostayer.new (2026-05-30): образ docker.stostayer.ru/vehicles-loader:0.4.0 собран (811MB, digest sha256:f2e10b1f090ba47f9b5de83b84f91c5ce827ecaf1e94bc0331f2d6773f85845a), docker login BA-кредами → docker push (общие слои с 0.3.0, докинуты только app-слои). verdaccio-депы из .yarn/cache запеклись при build.
• На хосте клиента (ssh victor@new.stostayer.ru:20435, docker через sudo -S): docker pull …:0.4.0 (digest совпал) + docker tag …:0.4.0 vehicles-loader:latest. :latest теперь 0f8a4dd46236 = 0.4.0; 0.3.0 (5407c0563e44) оставлен под rollback.
• Плановый прогон отстрелял Sun 2026-05-31 06:21:48 → 07:53:14 MSK на changed-выгрузке (не skipped — 1С перезаписала файл в 6:00, checksum разошёлся).
• Live-verify выполнен (2026-05-31): журнал показал движение по всем фазам — ▶ branches/vehicles/units/delete-sweep — start, батч-прогресс (manufacturers: 18/183 … 183/183, units: 3/26 … 26/26), ✓ … done: N rows, per-model delete-sweep … 0 — выгрузка полная. НЕ тишина. Finished … Deactivated successfully = exit 0. importRun id=4 ok, reportJson errors:[].

Acceptance criteria

• Образ docker.stostayer.ru/vehicles-loader:0.4.0 собран здесь и доступен на хосте клиента, :latest указывает на 0.4.0.
• В journalctl -u vehicles-loader.service боевого прогона видно движение по фазам + батч-прогресс + per-model delete-sweep counts (не тишина после трёх Total …).
• Данные залились корректно (importRun новый ok-ряд), email-отчёт ушёл (попутно закрывает остаток «живой email-SEND в составе sync» из vehicles-loader-image-distribution).

Decisions log

• 2026-06-01: прод-подтверждение за 01.06 (опц. follow-up из хендоффа закрыт). Плановый прогон 06:20:45→07:55:22 MSK, importRun id=5 status=ok, errorMessage=NULL, exit 0. Progress-logging показал движение по всем фазам (batch units 26/26, per-model delete-sweep 0 — выгрузка полная). Counts: vehicles 3884, units 100529, service updated:103. Email реально дошёл до gmail (user подтвердил «письмо пришло») — фикс адресата отработал на боевом прогоне, не только на тест-письме. generation unmatched:51 стабилен (== id=4 за 31.05) — не регрессия, остаётся follow-up'ом.
• 2026-05-31: CLOSED 🟢. Live-verify прогона 06:21→07:53 MSK прошёл (см. Pending ops actions). Progress-logging работает как задумано. units-фаза = 1h 31m на 100529 rows (узкое место, кандидат на оптимизацию — follow-up, не блокер). generation unmatched:51 — глянуть отдельно.
• 2026-05-31: email-баг найден и починен. 4-й acceptance («email ушёл») валился молча: STOSTAYER_MAIL_TO=site@stostayer.ru в /etc/stostayer/vehicles-loader.env — отчёт слался сам себе, а не user'у. Отправка отрабатывала успешно (потому прогон и ok), адресат неверный. Фикс: STOSTAYER_MAIL_TO=vitya.kuznetsov@gmail.com (бэкап vehicles-loader.env.bak.20260531), FROM=site@stostayer.ru без изменений (это и есть SMTP-аккаунт релея mail.stostayer.ru). Доставка подтверждена тест-письмом из контейнера: ACCEPTED=[gmail], 250 queued as 8732C122F18. Хвост: в репо config/default.json дефолт to всё ещё site@stostayer.ru (прод перекрыт env) — опц. выровнять в stostayer.new.
• 2026-05-30: build+push+host-deploy выполнены. Образ 0.4.0 собран здесь, запушен в docker.stostayer.ru, на хосте pull + re-tag :latest → 0.4.0. 0.3.0 retained для rollback.
• 2026-05-30: open question #1 (push кода) снят — a74ef73 оказался уже в origin/master (git branch -r --contains a74ef73 → origin/master), дерево чистое. Билдил из чистого дерева, Rule-4-вопроса нет.
• 2026-05-30: open question #2 (verify-окно) решён user'ом = ждём natural 06:20 (Sun 31.05), НЕ форсим baseline-reset. Причина: форс = внеплановое email-письмо клиенту + спурьёзный ре-импорт; natural-прогон и так = боевой acceptance. Trade-off: verify unattended, в след. сессии.
• 2026-05-30: заведено из stostayer.new session по явному указанию (закрыть код-таску by-inspection, live-verify вынести в .admin как deploy-follow-up).

Open questions

• Push stostayer.new master нужен до build? — нет, a74ef73 уже в origin/master.
• Где взять changed-выгрузку? — ждём natural 06:21 Sun 31.05 (1С перезапишет файл в 6:00).

Notes

• Схема деплоя 0.3.0 + обе инфра-гочи (IPv4 DB host; custom /etc/hosts для mail-DNS) — stostayer.new/.wiki/concepts/client-infra-access.md + vehicles-loader-docker-deploy.md.
• Источник: stostayer.new/.tasks/vehicles-loader-progress-logging.md (🟢 closed by-inspection), commit a74ef73.
• Предшественник: .admin vehicles-loader-image-distribution (🟢 closed 2026-05-29) — канал поставки + первый боевой прогон 0.3.0.