Files
transcriber/tasks/items/dev-run-task.md
T
av a8fb4793be закрыта задача trusted-header-login
- две записи, ссылавшиеся на убранный oidc-login, переписаны
- dev-run-task переведена с отдельного cmd/devadmin на подкоманду cmd/devtools
2026-08-22 20:25:13 +03:00

6.2 KiB
Raw Blame History

🧹 Поднимать сервис для локальной работы одной командой

  • Тип: chore
  • Категория: Очередь — оснастка локального прогона: без неё каждую проверку начинают с двух терминалов и ручной уборки
  • Зачем: Локальная проверка требует ручной чистки каталога данных и остановки процесса, а владельца панели заводят по одноразовой ссылке из журнала.

Шаг task dev CONFIG=<путь> USER=<имя> поднимает сервис, кладёт данные во временный каталог, заводит владельца панели и гасит процесс по Ctrl+C.

Работа состоит из двух частей, и они едут одним коммитом: инструмент подкоманда cmd/devtools admin и шаг dev, который её зовёт. Порознь они не нужны — шаг без инструмента не заведёт владельца панели, инструмент без шага останется вызовом, который никто не делает.

Заглушки провайдера здесь больше нет: вход переезжает на доверенные заголовки задачей trusted-header-login, и обычная учётная запись заводится первым же запросом с заголовком. Каким способом заголовок попадает в запрос на машине без прокси, решает та задача; этот шаг её решение только зовёт.

Задуманное устройство:

  • конфиг пишет человек и передаёт путём — шаг его не сочиняет;
  • шаг подменяет каталог данных: кладёт копию переданного конфига во временный каталог со своим data_dir, чтобы прогон начинался с пустой базы независимо от того, что написано в конфиге. Временное живёт в /tmp — в data/ писать запрещено (CLAUDE.md, «Запреты»);
  • владельца панели заводит подкоманда cmd/devtools admin. Пакет оснастки уже заведён задачей trusted-header-login и в образ не едет; своего пакета заводить не надо — решение владельца 2026-08-22: инструмент оснастки стоит четырёх мест, и платить их надо однажды. Базу подкоманда открывает тем же pbrepo.New, что и сервис, и потому получает её со схемой целиком; зовётся до подъёма сервиса, на пустом каталоге. Пароль существующего владельца не переписывает;
  • обычная учётная запись заводится первым запросом с заголовком: имя берётся из USER, и заводить её отдельно шагу не нужно;
  • trap на INT и TERM гасит процесс, wait держит терминал.

Затрагивает

  • cmd/devtools — подкоманда admin рядом с готовой proxy: заводит владельца панели в базе;
  • Taskfile.yml — шаг dev с переменными CONFIG и USER;
  • скрипт запуска в scripts/ — он попадает под шаг shell гейта;
  • CLAUDE.md, раздел «Команды»;
  • README.md, раздел про локальный запуск;
  • Dockerfile — строка сборки называет точку входа поимённо; новых пакетов не прибавляется, и правки ей не нужно.

Критерии приёмки

  • Команда поднимает сервис и печатает адрес, по которому открывать приложение, вместе со способом представиться. Оракул: прогон с тестовым конфигом — сервис слушает свой порт, названный адрес отвечает.
  • Ctrl+C гасит процесс и не оставляет висящих. Оракул: pgrep по имени после остановки — пусто.
  • Владелец панели входит своим паролем, а первый запрос с именем из USER заводит учётную запись. Оракул: вход по auth-with-password в коллекцию владельцев и запрос к коллекции пользователей во временной базе.
  • Каталог данных лежит во временном месте, а data/ не тронут. Оракул: путь базы из журнала подъёма и git status после прогона.
  • task gate остаётся зелёным, скрипт проходит shellcheck, а образ не получает нового пакета. Оракул: прогон гейта целиком и task image.

Рамки

Шаг локальный: наружу не ходит, боевых ключей не требует и в образ не попадает. Идёт после trusted-header-login — до неё локальный вход устроен иначе. Пароль владельца в конфиг не заводится — требование спеки storage «Пароль владельца от панели не лежит в конфигурации» остаётся в силе, и работа его не трогает. Распознавание при выдуманных ключах не работает — это остаётся как есть, шаг его не подменяет.