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 (та же схема, что 0.3.0, см. vehicles-loader-image-distribution closed-блок): docker build -f packages/vehicles-loader/Dockerfile -t docker.stostayer.ru/vehicles-loader:0.4.0 . docker push docker.stostayer.ru/vehicles-loader:0.4.0 (verdaccio-депы запекаются при build здесь — клиенту verdaccio не нужен.)
• На хосте клиента: docker pull docker.stostayer.ru/vehicles-loader:0.4.0 + re-tag :latest (systemd-юнит запускает :latest).
• Дождаться планового прогона (systemd timer 06:20 MSK) или прогнать вручную systemctl start vehicles-loader.service на changed-выгрузке (на unchanged будет skipped-unchanged, прогресса не будет — нужен изменённый zip или сброс baseline).
• Live-verify: journalctl -u vehicles-loader.service -f (или --since) — видны ▶ … start, периодический батч-прогресс, ✓ … done, per-model delete-sweep.

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-05-30: заведено из stostayer.new session по явному указанию (закрыть код-таску by-inspection, live-verify вынести в .admin как deploy-follow-up). Push кода НЕ сделан (Rule 4) — деплою предшествует push master или build из локального дерева.

Open questions

• Push stostayer.new master нужен до build, или билдим из локального рабочего дерева? (commit a74ef73 пока только локально.)
• Где взять changed-выгрузку для немедленной проверки, или ждём естественного изменения units.json к ближайшему 06:20?

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.