Справочник

Архитектура

Каждая команда стартует с одного и того же конфиг-файла (roots/packages/gitlabHosts), разворачиваемого в плоский список репозиториев. Read-only проверки (git-статус, поиск тега/релиза/реестра/PR) выполняются через небольшой параллельный map с ограничением по конкурентности, так что полный list или doctor по многим репозиториям не ждёт каждый репозиторий по очереди. Всё, что меняет состояние — коммит, push, merge, тег — идёт через один общий слой выполнения git/npm (плюс gh или glab, по каждому репозиторию отдельно), который всегда печатает команду, которую собирается выполнить, и для мутирующих шагов одинаково для всех команд учитывает --dry-run.

Специфичная для хостинга логика (создание и merge PR/MR, ожидание CI, создание релиза, защита ветки, определение основной ветки) живёт за одним общим интерфейсом с двумя реализациями — GitHub-адаптер поверх gh и GitLab-адаптер поверх glab. Каждая команда, которой нужен хостинг репозитория, определяет его сама, по git remote get-url origin, а не получает готовым — см. «Конфиг и поиск репозиториев».

bump — единственная команда с реальным состоянием, которое нужно отслеживать между запусками: вместо того чтобы хранить что-то самому, она каждый раз заново вычисляет, как далеко зашла предыдущая попытка (запушена ли ветка? открыт ли PR/MR? смёрджен ли он?), прямо из git/хостинга при каждом запуске — именно это делает повторный запуск после прерывания безопасным, без какого-либо локального состояния, которое могло бы устареть.

Команда не печатает напрямую: она сообщает о ходе работы через небольшой рантайм (заголовки, шаги, строки статуса, таблицы, прогресс и вопросы, которые она задаёт), а терминал и веб-интерфейс — две его реализации. Терминальная печатает то, что команды печатали всегда, и спрашивает через prompt'ы. Веб-реализация превращает те же вызовы в события, которые рисует страница, и каждый запуск идёт в своём дочернем процессе, так что два запуска, или запуск и его отмена, никогда не делят состояние. Поэтому polyrepo ui может запускать любую команду, а вывод в обоих местах одинаковый.

Сравнение

Более узкий по охвату инструмент, чем оркестратор сборки монорепозитория (Nx, Turborepo, часть Lerna, отвечающая за запуск задач) — polyrepo-cli не строит граф зависимостей задач и не кеширует их результат, потому что рассчитан на папку независимых репозиториев, у каждого из которых свой package.json и свой remote (GitHub или GitLab), а не единый workspace. Он также не заменяет инструмент версионирования/changelog вроде Changesets — черновик записи в CHANGELOG.md он пишет как часть bump, но реально автоматизирует именно git/хостинг/npm-механику релиза (ветка, PR/MR, merge, тег, релиз, публикация в npm) сразу по многим репозиториям, а не накопление changeset'ов внутри одного.

Разработка

git clone https://github.com/macrulezru/polyrepo-cli.git
cd polyrepo-cli
npm install
npm test
npm run dev:ui      # интерфейс с горячей перезагрузкой, при работающем `polyrepo ui`
npm run build:ui    # собирает интерфейс в ui-dist/

Юнит-тесты покрывают чистую логику, не требующую настоящего git/gh/glab/npm — бамп версии, вставку записи в CHANGELOG.md, обнаружение рассинхронизации зависимостей между пакетами и переписывание диапазонов (для sync-deps), определение dist-тега (для publish), распознавание имён bump-веток и определение хостинга по URL удалённого репозитория — с использованием настоящих временных файлов на диске, а не моков. У веб-интерфейса свои тесты, которые запускают сервер на свободном порту и работают с ним по HTTP: токен доступа, API конфига, запуски и их вопросы, отмена, история и сохранённые наборы.

Лицензия

MIT — см. LICENSE.